SealedClassSerializer currently requires to OptIn to InternalSerializationApi

[floschu]

What is your use-case and why do you need this feature?

We use SealedClassSerializer to manually generate KSerializers for sealed classes/sealed interfaces that are out of our scope and cannot be annotated with @Serializable and auto generate KSerializers.

This works currently and we use it, however we fear that due to the fact that it is an effective internal api, the implementation could change on a minor version release.
In the end, if this change would happen and would break our code, we could then still copy the internal code of the previous version and use it, but it would be nice to have a public way to manually do serialization of sealed classes. :)

Describe the solution you'd like

1. Maybe there is something we are missing and there is a public way to serialize sealed classes which we have not found? 🤔
2. If not, do not require SealedClassSerializer to OptIn to InternalSerializationApi.

[sandwwraith]

No, there's currently no such way to write a sealed class hierarchy by hand. You're right, this feature is long overdue — see also #1865

[pdvrieze]

Looking at this issue and #1865 what we are effectively doing is saying that we have a serializer that is somewhat polymorphic, but has a fixed set of subtypes defined by the serializer/serial descriptor rather than using a SerializersModule, independent of whether that type is actually sealed (per Kotlin).

Interesting to note is that the documentation for SEALED and OPEN actually mentions that the serializers are merely examples. This means that it must be possible to make things work without special treatment of SealedClassSerializer or PolymorphicSerializer. A custom serializer thus should be possible (I know generic buildSerialDescriptor is still experimental ;-), but not needed.