@Optional annotation seems excessive about kotlinx.serialization HOT 11 CLOSED

I prefer we infer Optional and you override with Required in the cases where you don't like the default behaviour. This would also match some other implementations of data binding that have been around a bit setting expectations :-)

from kotlinx.serialization.

@elizarov @pdvrieze @sandwwraith
Can you take look at this issue once more?

I think that every field can be optional by default (or this option can be specified via Json constructor) and doesn't throw exceptions if it has default value.
In my situation I have client-server architecture. Configuration files can be edited by a user. He can make a mistake and then default value should be used since I don't want to give up and allow to server to die. Default values exist for every field and they are safe for every user.

What do you think now after year while this issue exist?

from kotlinx.serialization.

I second the idea of removing Optional and replacing it with Required.

At the very least Optional should be implied for nullable types.

from kotlinx.serialization.

+1 to @rawnsley 's At the very least Optional should be implied for nullable types.

If you have strong reasons to keep the existing functionality by default, another way is to make a global strategy and one to chose for himself:

@Serializable
data class Foo(
		val name: String?
)

Json(implyNullOptionals = true).parse(Foo.serializer(), "{ }") // this should print Foo(name=null)

from kotlinx.serialization.

Seems there are no cases when this feature would do any harm, so starting from 0.11.0, optional annotation is deprecated and no longer required. Any properties with default values are considered optional.

Please note that you have to use Kotlin 1.3.30 or higher.

from kotlinx.serialization.

We've decided to require it there to be explicit about optionallity (at least initially). It also helps when you start moving your properties between primary constructor and class body. The parameters in the class body must always have an initialization expression, but it may not be conceptually appropriate to tread all of them as implicitly optional. Or maybe it is appropriate. We can reconsider this, but it really needed a larger design discussion.

from kotlinx.serialization.

In the current state where optional values are always written anyway this may be an option, but if we have optional mean that writing may be omitted by the format(encoder/decoder) a default optionality can create surprising effects.

from kotlinx.serialization.

The way the system works is that missing values are actually verified by the (generated) (de)serializationstrategy. Any format would struggle supporting this as it would need to keep its own account of missing non-read values and implicitly read nulls. This is actually what my XML library does - it treats missing values as null (for now it doesn't yet look at optionality as that was not visible in older versions).

It may be possible to create proxy strategies that make this work with default formats. I think that would probably be the way to go.

from kotlinx.serialization.

@sandwwraith What is alternative when kotlin version is < 1.3.30.
Mine is 1.3.21 and not able to find any documentation for this.

from kotlinx.serialization.

@aayush26 Why don't you update to Kotlin 1.3.61?

from kotlinx.serialization.

@aayush26 Specify @Optional explicitly. New library versions do not work with old Kotlin versions anyway.

from kotlinx.serialization.