-
Notifications
You must be signed in to change notification settings - Fork 612
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
Consider to implicitly apply Serializable annotation to the entire sealed hierarchy #2572
Comments
Given that inheritors of the sealed interface can be defined anywhere in the project, and it is not mandatory for them to be in the same file, this would be hard from a technical standpoint: it would require the plugin to analyze every single class in the project and its superclasses, instead of focusing on To sum up, we cannot change the behavior of the existing |
|
|
In some way the serializable annotation adds an expectation to the type (in that a valid expectation could be that all its subclasses/implementations are also serializable). On the other hand there may be implementations that can not be serializable (and the parent must be to support serializability of the sibling) – This is more of an "abstract serializability" (often with abstract base types). Given this dichotomy it seems that either a different annotation (or parameter) would work (as well as maybe have the plugin generate warnings on missing child serializers). The biggest challenge I see is the change of annotations being an API change |
What is your use-case and why do you need this feature?
Parcelize allows the following code.
We are able to specify the annotation only once on the base
State
interface. Withkotlinx-serialization
we have to repeat the annotation for every implementing class, which is pretty verbose.Describe the solution you'd like
It would be nice to be able to write as follows.
Alternative API if changing the existing behaviour is undesirable.
The text was updated successfully, but these errors were encountered: