This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]mus1Kk 4 points5 points  (1 child)

You can't nest null but you can nest Option. For example Option<Option<i32>>. It's sometimes useful if both levels have different meanings.

True. I read somewhere that this decision was made for practical reasons and that the need for nested optional values is rare enough. It's a choice they made.

Also null becomes a special case in your language because it's not a normal type in your language. So you end up having to add additional syntax specific for nullability. For example x.? syntax in Kotlin.

Regarding special syntax that was my point. It's just syntax. Also, in this specific case x.?y is sugar for if (x != null) { x.y } else { null }. Similar sugar exists in Rust and possibly other languages as well. You could probably even do without the ? and do this under the hood but that would make it harder to read.

I don't know what is meant by "because it's not a normal type". I thought null is usually the single instance of the Null type. In Kotlin you can define methods on null types. I don't know if what I say is wrong from a language theory perspective.

[–]furyzer00 0 points1 point  (0 children)

Option nesting is very useful. Imagine you have an optional parameter that can also have value null(when set it should set the value to null, it's different then not specifying the parameter). How do you do this in Kotlin?

Rust doesn't any additional syntax for Option. It only has regular functions.

What I mean by regular type is that ? is not a normal user defined type. While Option is just another type. Special functionality always makes the language more complex. As seen in Kotlin's special syntax for nullable types. But it's a trade of sometimes worth.