Stabilize encoding and decoding of value classes

[qwwdfsad]

No description provided.

[qwwdfsad]

When we have this sorted out, I'll update the guide

[whyoleg]

just interesting: in future value classes will be able to have multiple properties (multi-field value classes KEEP) - how then kx.serialization will work with them?
Even if for now inline class = value class, may be it will be better consider in mind, that it will change.
And, f.e. introduce separate annotation like InlineSerializable which will work not only with inline/value classes, but even with any other ordinary class or even interface?

[qwwdfsad]

how then kx.serialization will work with them

It's hard to tell without an actual design and implementation of multi-field value classes.

If the language will change the notion of value classes, we will of course have to change these methods accordingly

[sandwwraith]

I'm not sure it is the right approach just to do s/inline/value. For example, there is a statement that now says 'value classes always have one property' — it may become a false statement in the observable future. Moreover, we simply can't encode several properties of value class via decodeInline, so this method would become irrelevant. Inlining in the Kotlin itself is also controlled by @JvmInline annotation, not by value keyword.

In my point of view, we should coin our definition of the words 'inline class' that would mean @JvmInline value class or just that that class' property is 'inlined' into the output without class wrapping — regardless of Kotlin class definition. By doing this, we would be able in the future to serialize regular value classes with any number of properties as regular classes, and, probably, use encodeInline for classes that have one property but are not necessary @JvmInline value classes.

[qwwdfsad]

I'm not sure it is the right approach just to do s/inline/value.

But this is not what this PR does! It is, in fact, already addresses most of your concerns. We still have all methods named inline with the documentation "Returns [Encoder] for encoding an underlying type of a value class in an inline manner."

"an underlying type of a value class in an inline manner" is exactly the terminology I aim for.

there is a statement that now says 'value classes always have one property'

There isn't in our documentation. While we cannot foresee every potential language feature, here we can do an additional safety net and specify "encoding an underlying type of a value class with a single property in an inline manner.". Though, honestly, it may create a false perspective that there are value classes with multiple properties. I would rather add this "single property" clarification at the moment when multi-word value classes are started being worked on.

[sandwwraith]

There isn't in our documentation

https://github.com/Kotlin/kotlinx.serialization/pull/1963/files#diff-4a1e3a83f12e9a0e4248e1bf4189959538582dd980394eee44faec9516dfe1a5R510