Introduce @SealedSerializationApi to codebase and stabilize part of SerialDescriptor's API #2827
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Build with Kotlin master failed because of Kotlin/dokka#3851 |
shanshin
approved these changes
Oct 8, 2024
| * Yet it is not type-checked statically, thus making it possible to declare a non-consistent implementations of descriptor and serializer. | ||
| * In such cases, the behaviour of an underlying format is unspecified and may lead to both runtime errors and encoding of | ||
| * Yet it is not type-checked statically, thus making it possible to declare a non-consistent implementation of descriptor and serializer. | ||
| * In such cases, the behavior of an underlying format is unspecified and may lead to both runtime errors and encoding of |
There was a problem hiding this comment.
We use both options, is this change definitely necessary?
There was a problem hiding this comment.
IIRC general doc guideline dictates the usage of American English, so all spelling should be converted to this one eventually
qwwdfsad
approved these changes
Oct 8, 2024
lukellmann
reviewed
Oct 9, 2024
core/commonMain/src/kotlinx/serialization/descriptors/SerialDescriptor.kt
Show resolved
Hide resolved
core/commonMain/src/kotlinx/serialization/descriptors/SerialDescriptor.kt
Show resolved
Hide resolved
This API has been around for a long time and has proven itself useful. The main reason @ExperimentalSerializationApi was on SerialDescriptor's properties is that we wanted to discourage people from subclassing it. With the introduction of @SubclassOptInRequired (#2366), we can do this without the need of marking everything with experimental. Serial kinds fall into the same category with only exception in PolymorphicKind. There are plenty requests for functionality like creating a custom sealed-like descriptor (#2697, #2721, #1865) which may require additional kinds in the future.
and allow creating primitive descriptors via it as well. This constructor function is a way to create a descriptor for your custom serializer if it simply delegates to an existing one. Since it fits its purpose and is unlikely to change in the future, we can promote it to stable API alongside other descriptor builders. Fixes #2547
to be used with @SubclassOptInRequired. This annotation allows for even more fine-grained API marking. We now can designate APIs as public for use, but closed for implementation — the case for SerialDescriptor, which is a non-sealed interface for technical reasons.
sandwwraith
force-pushed
the
subclass-optin-required-2
branch
from
aed3864 to
4e7eed3
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Same as #2764 but without
@AdvancedEncodingApi. It seems that https://youtrack.jetbrains.com/issue/KTIJ-30831 is fixed only in K2 IDE and only in Kotlin 2.1, so introducing@AdvancedEncodingApinow may lead to poor UX for 3rd party format authors