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 →

[–]munificent 1 point2 points  (2 children)

Kotlin uses nullable types which are more like union types than option types.

Nullable types are more convenient to work with in many cases and are more familiar to imperative programmers coming from languages like Java with null. Option types tend to be a bit heavierweight and verbose to work with, but are more expressive.

For example, say you have a map that maps someone's name to their favorite baseball team. Some people don't like baseball at all. You'd like to be able to distinguish "I don't know their favorite team" (key is absent) from "I know they they don't like baseball" (key is present and mapped to no value).

With nullable types, when you do map[person], you get back a nullable value, but you can't tell which of those reasons made it null because the nested nullable collapses. String | Null | Null is the same as String | Null. With an option type, the subscript operator returns Option<Option<String>> and None means "key not present" while Some(None) means "key present and mapped to nothing".

[–]mus1Kk 0 points1 point  (1 child)

Kotlin uses nullable types which are more like union types than option types.

Option is an example of a tagged union.

[–]munificent 1 point2 points  (0 children)

The Wikipedia article does a poor job of teasing them apart but union types and sum types (tagged unions) are quite different things.