undefined | Better HN

0 pointsFilligree9y ago0 comments

Nullable types are fine. The key is to make them explicitly nullable, so that programmers are allowed to use non-nullable types as well.

Both need to be permitted. Ideally by way of sum types, but Kotlin's approach should be okay.

0 comments

3 comments · 1 top-level

sanderjd9y ago· 2 in thread

Why do you need both? Are there use cases for null that are not covered by a (non-nullable) type with present and absent variants?

clappski9y ago

I think the distinction between nullable types and the non-nullable types you speak of is fairly narrow, you've just made it type safe (which isn't a bad thing!).

sanderjd9y ago

I don't necessarily disagree, what I don't understand is the parent comment's use of the word "need" in "Both need to be permitted". It makes me think there is something nullable types can do that non-nullable types can't do, and I'm just not sure what that is. Something like "it is fine to permit both" would make sense to me.

I guess maybe it's because in a language with no value types (like anything on the jvm), using Optionals everywhere requires a lot more objects to be allocated, so in allocation-sensitive code it might make more sense to use nulls instead.

j / k navigate · click thread line to collapse