To answer myself :point_up: , the issue is not sea...

# multiplatform

[dambakk]

To answer myself ☝️ , the issue is not sealed classes I believe but rather that kotlinNothing is not a sub-type of NSString. However, the situation above is an implementation of how this article suggests dealing with serializing nullable and optional properties which I think is overengineered. Instead of using the sealed class to represent the three states present-with-value, present-with-null-value, and not-present you can instead have a data class OptionalProperty<T>(val value: T) and use it as a nullable property type and still cover all the states. It works as before, but is now much more pleasant to use from swift. But please correct me if I’m wrong.

[Petter Måhlén]

do you mean data class OptionalProperty<T>(val value: T?)? otherwise, I’m struggling a bit with understanding 🙂 but I think you’re right that you can distinguish the cases with that solution. As in,

val missing: OptionalProperty<String>? = null
val presentNull: OptionalProperty<String>? = OptionalProperty(null)
val present: OptionalProperty<String>? = OptionalProperty("foo")

[dambakk]

I think you got it! 🙂 either T may be nullable or you can use it like val presentNull: OptionalProperty<String?>? = OptionalProperty(null). Potato, tomato 🙂 Is anything else unclear? Also, a custom serializer is still needed as explained in the linked article (somewhat changed tho)

[Petter Måhlén]

i think i prefer ‘potato’/`T?` 🙂 in the sense that the OptionalProperty wrapper doesn’t seem meaningful unless the wrapped property can be null. Also, I think I prefer this version to the sealed classes one. I have a feeling that I saw somewhere some Swift code that used double-optionality (T??), but that doesn’t seem to work in Kotlin. Also, not quite sure that I remember right.