Stable release & move to Retrofit repo

Hi! As far as I understood from #43 the last thing that prevents this lib from being an official converter in the Retrofit repo is that it depends on the experimental parts of kotlinx.serialization API.

We’ve removed experimentality from StringFormat/BinaryFormat in 1.3.0 release. Am I right that serializer(java.lang.Type) is the only experimental function blocking this?

If so, can you please provide some feedback on it — whether it does the right thing, or some functionality is missing, etc. We’re going to stabilize it soon so converters like this can depend on a stable API.

[JakeWharton]

Thanks! I’m going to release a stable version of this library for simplicity, and then will migrate it to Retrofit for its next release.

[sandwwraith]

We’ve been revisiting the design, and while the function is likely to stay, I’d like to ask about the problems with nullability:

Because Java’s type tokens do not contain this information, serializer(Type) always returns non-nullable serializers for all nested types. In practice, this means the following code:

interface MyApi {
  @Get("foo")
  fun getFoo(): List<String?> // or any other nullable type in any position
}

Would fail with deserialization error on the input like ["a", null]. Have you experienced this problem? How severe is it for you?

We currently have several proposals on what to do with it:

1. Do nothing — if the problem is non-existent in real life
2. Always wrap all serializers to .nullable inside this function. This would make this function unusable for formats that strictly differentiate nullable vs non-nullable: while Json format can deserialize non-null value with nullable deserializer, Protobuf can’t.
3. Change signature/provide an additional function with an additional parameter that can alter this behavior. Either serializer(type: Type, wrapIntoNullable: Boolean) or more sophisticated serializer(type: Type, typeArgSerializerFactory: (Type) -> KSerializer<*>) (latter would also probably cover https://github.com/Kotlin/kotlinx.serialization/issues/2025).