There’s been some code produced that’s created mixed feelings in the team. I’d love to hear your fee...

# codereview

[Can Orhan]

There’s been some code produced that’s created mixed feelings in the team. I’d love to hear your feedback on it.

This class was created to give meaning to why a value would be missing within a model

sealed class UserInput<out T : Any> {
    data class Value<T : Any>(val output: T) : UserInput<T>()
    object Missing : UserInput<Nothing>()
}

The problem with it is that we can’t use Kotlin’s null-safe operators like :? and .? .
Do you think there is value in knowing why something is missing? If so, is it worth the loss of null-safe operators?

[Mike]

Is this really telling you why it's missing? This is effectively a custom Option/Optional class, so I don't see any value over UserInput? as the type.

[Mike]

In Java, one would use Optional for this, as it doesn't allow one to differentiate between a String and a String that may be absent.

Kotlin doesn't require Optional BECAUSE of null being part of the type system. So I'd say this is a perfect case where Kotlin is stronger, and one should use the language features.

[Can Orhan]

While I’m definitely leaning towards using the language’s null-safe features, though the two classes are structurally similar, I think that there’s enough of a contextual difference that the naming gives. Really appreciate your feedback!

[Zach Klippenstein (he/him) [MOD]]

If you decide the explicit typing is worth it but still want syntactic sugar, it's trivial to define a family of operators on this type that let you write fluent code.

[Mike]

You could also use an inline class for this. inline class UserInput<T>(val value:T). And then define type as UserInput<String>? when it could be missing, and then once it exists, functions can take the non-null version.

[Mike]

All depends on how you want to write your code/functions.

[Zach Klippenstein (he/him) [MOD]]

compiler complains about that for me

[Mike]

Hmm, ok. Actually, that makes sense as it has to inline the type. Will your user input type actually change?

So you could just use a regular class, and have it be nullable. Apologies for that.

[Zach Klippenstein (he/him) [MOD]]

That said, this is how the built-in Result type works and the compiler is actually generating bytecode for this that looks reasonable, so I think it’s probably one of those “experimental” things.

[Can Orhan]

We’ve dropped the use of it but I think it’s still an interesting thing to talk about 😄
@Mike Oh thanks! I need to read into what the inline keyword does…
@Zach Klippenstein (he/him) [MOD] I was thinking the same - though a lot of the functions added would fuel the thought that it really looks a lot like an Optional 😄
What I tried to do was to create a typealias for null but that’s obviously not supported.
I also looked into creating a contract or operator overload where I could express to the compiler that returns(x !is Missing) implies (this is Value) but couldn’t find anything that’d help