New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use-site annotation to require type is serializable #2605
Comments
The only one I can remember is #2522. It was not about annotation but about reporting an error in every case. However, I'm not sure how you expect this annotation to work with the dynamic natures of the modules. In your example,
But this is incorrect. I can have
Because if default serializer is not found, we always look into the module at runtime. |
If this was a class and property, e.g. data class MaybeSerializable(val prop: MyNonSerializableClass) IIUC the compiler would complain, and it would require I think behavior would make sense here, too, so that: val factory = DefaultFileRepositoryFactory(serializersModuleOf(MyNonSerializableClassSerializer))
factory.create<MyNonSerializableClass>() // returns MyNonSerializableClassSerializer would have an error, but val factory = DefaultFileRepositoryFactory(serializersModuleOf(MyNonSerializableClassSerializer))
factory.create<@Contextual MyNonSerializableClass>() // returns MyNonSerializableClassSerializer would work. It matches the behavior we're used to with classes, where |
I find this confusing. The factory already returns contextual serializer without additional annotations, why should we report an error on a valid code that returns the expected result? |
Because the point of using Just like for serializable classes, there may be cases where a serializer would be found, but it still errors, because it can only statically check things.
I don't think you'd need to, it's just a compile time check. |
I second the desire for such an annotation. In fact I'd prefer it if the existing However, I also understand that it can be considered a breaking change, because code that previously compiled suddenly doesn't anymore due to a missing annotation. It could thus be initially introduced as a warning and made an error in a future major release. |
I could swear there was an issue for this somewhere, but I couldn't find it. May be a duplicate.
What is your use-case and why do you need this feature?
The serialization plugin has some very nice type checking to ensure that property types are all serializable when a class is annotationed as serializable. For example:
would highlight
MyNonSerializableClass
as an error.I would like the ability to extend this checking to user code (that is not just serializable class definitions). Why? Because often times you have a method that has an argument that you know you will be looking up a serializer for later. It would be nice to be able to have a compile-time error when passed a known non-serializable type rather than a runtime error.
For example:
(
@RequireSerializable
is what I'm proposing)This comes up when you are using a DI framework that manages your serializers module and/or serialization format. In that case, you don't want to have to inject the module and get a serializer at the high level, but to pass the type down to the level actually doing the serialization. This is also important if you are supporting multiple serialization frameworks.
Another use-case is where you have an open interface, and want to ensure you are passed only serializable sub-classes:
In this case, rather than being done manually, the later lookup is done by polymorphic serialization.
Another potential solution to this particular use-case is a way to have an open interface that requires all concrete implementations to be serializable.
Describe the solution you'd like
I would like a
@RequireSerializable
annotation that can be applied to types. This applies the "should be serializable" type checking the plugin already uses for serializable class properties to the type, and whenever it is used. For example, in the second example, it would be fine applying it toWindow
since it is an interface. However callingopen(BadWindow(3))
would error, since semanticallyBadWindow
is not of type@RequireSerializable Window
(since it is not serializable).I think a fine alternative for the second use case would be to require it to be a generic type, e.g.
The text was updated successfully, but these errors were encountered: