[hexane360]

This often comes up when writing a function which returns a wrapper over a generic type (like Option<T>). If your Option type is T | null, then there's no way to distinguish between a null returned by the function or a null that is part of T.

As a concrete example, consider a map with a method get(key: K) -> Option<V>. How do you tell the difference between a missing key and a key which contains `null` as a value?

[brabel]

This is trivial to model by making your type `T | null | Missing`.

[epolanski]

Or just using Option since you would have Some<null> or None in that case.

[efnx]

Maybe trivial to “work around” but there is a difference, ay?

With this type you would have to check/match an extra case!

The type you use there also takes more memory than Option<T> or Maybe<T>. So it has some other downsides.

[hexane360]

Only if you're designing both functions ahead of time. In other words, it's not composable.

[epolanski]

`T | null` is equivalent to T. You can assign null to `T`>

It's like saying `string | "foo"` it is simply `string` due to subtyping.

[hexane360]

... no? Unless you're referring to null as a bottom type, then that doesn't hold. Are you describing some property of a specific language?