Skip to content
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

Introduce @SubclassOptInRequired to codebase and stabilize part of SerialDescriptor's API #2764

Open
wants to merge 3 commits into
base: dev
Choose a base branch
from

Conversation

sandwwraith
Copy link
Member

No description provided.

@sandwwraith
Copy link
Member Author

@qwwdfsad, although I'm not sure if we should introduce it now since https://youtrack.jetbrains.com/issue/KTIJ-30831 may lead to a poor UX

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.

These annotations allow for even more fine-grained API marking. We now can designate APIs
as public for use, but closed for implementation (@SealedSerializationApi) — the case for SerialDescriptor, which is a non-sealed interface for technical reasons.

The other annotation, @AdvancedEncodingApi is aimed to provide guidance on implementing custom encoders/decoders by pointing users to a documentation and guides.

Fixes #2366
Copy link
Collaborator

@qwwdfsad qwwdfsad left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great job!

One meta-comment: eventually we'll switch to @sample that will be auto-runnable from kotlinlang and from IDE.
For that, you probably may want to change the sample form from

someFoo // computes to "kotlin.somefoo"

to the following

val someFooName = someFoo
print(someFooName) // Prints "kotlin.somefoo"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants