What are the pros and cons of an Option type in comparison to nullable types?

Question

There seem to be two main ways that languages handle the same concept:

• Nullable types, like Kotlin, C#, and many other OOP languages
• Options, like Rust and Haskell, which are wrappers around a type that can either be Some(...) or None (or equivalent names)

While these serve similar purposes, they do it in different ways. Having used and liked languages with both of these, what are the pros and cons of each?

Answer 1

Advantages of Option types:

• No need to implement flow typing, which can be hard to get right
• Can be used with primitive types (Int? would require boxing in a language with nullable types, removing the performance benefits)
• Can be nested - A function can accept an Option<T>, where T may itself be Option<Foo>. With boxing, it's possible to distinguish between a Some(None) and a None in this case. This isn't possible with nullable types (Int?? isn't a thing in Kotlin).
• Can implement interfaces such as Iterable or typeclasses such as Monad

Advantages of nullable types:

• Syntactically lighter - It can be cumbersome to write Option<T> and Some(x) everywhere, while in a language like Kotlin, you only need to write T? and x. Note: alephalpha pointed out in the comments that this isn't always true - the syntax for Zig's optional types looks similar to that of nullable types in other languages.
• With flow typing, once you check that a value is not null, you don't need to check again (in most circumstances). That means you can do if (x != null) x.foo(x.bar) rather than if (x.nonEmpty) x.get.foo(x.get.bar) or x.map(y => y.foo(y.bar))
• No boxing means that they take up less space and there's a performance benefit since you don't need to unwrap a Some/Just every time you want to access the value inside. As Bbrk24 mentioned in the comments, though, languages such as Rust and Swift can implement Options without boxing or with only a single bit to indicate whether the Option is empty, so this point only applies to certain languages. For example, Scala boxes its Options (although it's entirely possible to have nestable unboxed Options even in a language that doesn't natively support them, depending on your language's type system).

Answer 2

Special-casing

Another factor to consider is how much of a special case your approach to nullability will require. Option almost never requires any special handling in the compiler, as it can be defined as a simple datatype within the confines of the language.

On the other hand, nullable types can sometimes require a new specialized type within the type system. If Kotlin didn't have nullable types and everything was non-null forever, we wouldn't be able to ergonomically add nullable types to the language without modifying the compiler. Note that this isn't true in languages with union types, as "nullable string" can be written in a language like Typescript simply as string | null.

Answer 3

Option is an algebraic data type (ADT), so if your language already supports ADTs, you can implement Option in the standard library, whereas nullable types are implemented as a separate feature. Option may be passed as a type parameter because it allows nesting (e.g. Option<Option<T>>), whereas for nullable types, that is not necessarily the case.

On the other hand, Options usually have to be unwrapped explicitly using pattern matching, so nullable types may be more syntactically lightweight to use. This can be mitigated by adding syntactic sugar like Rust's ? operator.

Answer 4

Apart from @user's answer, there's usually the following convention for nullable types:

a?.b()?.c()

This it is intuitive to translate the above into

if (a != null) {
  b = a.b()
  if (b != null) {
    c = b.c()
    ....

However, it may also be the case that b() returns non-null, so the second null check is unnecessary. However, we may not write a?.b().c() because a?.b() as an expression is nullable!

This is not a problem in chained Option operations.

Answer 5

Nullable types are at the same level of indirection

Suppose I have the following Kotlin code:

fun foo(): Bar? {...}

val x = foo()
if (x != null) {
    doStuff(x)
}

If I later decide that Bar doesn't need to be nullable (perhaps because an external API changed) then I can simply remove the ? from the return type. While the users of my function now have no reason to do the null check, their code still compiles, albeit with a "redundant code" warning. If Kotlin had opted to use an Optional type instead, the users of my function can't recompile their code without changing it.

Credit to this HN post I saw yesterday for the basic idea.

Answer 6

Monad

It should be noted that usage of option types can be simplified by using monad and other functional programming facilities, and they do not need to be unwrapped everywhere.

For example, if you have two option values mx and my of Maybe Integer, you don't have to unwrap them and can add them using the do notation with monads:

do x <- mx
   y <- my
   pure (x + y)

If one of mx and my is Nothing, the return value will be Nothing. There is no need to case analyze whether mx and my are empty or not.

With the Applicative interface, one can also add the option values "directly":

pure (+) <*> mx <*> my

So, the syntactic burden of option types isn't necessarily heavy.

NULL

On the other hand, NULL values have many problems as already mentioned in other answers.

One good example is the SQL language. There is much ambiguity as to how NULLs should be handled or even interpreted. To this day, there is still inconsistencies among SQL aggregate functions as to whether they should return a NULL if the input is empty. Some return NULL (e.g. array_agg()) while others do not (e.g. count()).

Similarly, in practice, some users enter an empty string '' while others enter a NULL when a string field has no data.

Answer 7

Operators

Usually, nullable types and Options will provide special operators, like the Elvis (?:), for checking if they're null/asserting that they're not null/etc. Option types allow this to be implemented in a consistent manner within the language and easily overridden by other types, since they can just be implemented as operator functions using whatever syntax the language uses for those.