[jflwyasdf]

Right that depends if you subscribe to the belief that null means the absence of a value `Option<T>` or does it mean the zero value `T`.

[alkonaut]

If null and [] should be the same thing then I’d make absolutely sure you can’t represent both. You don’t want two states representing the same thing. That should be easy to ensure if a language is reasonable. E.g a field that can’t be null (best case a non-nullable type, otherwise maybe a constructor guaranteeing it’s never null)

As the example of byte vs option<byte> either you want 256 states or you want 257. If you have 256 or 257 states you want to represent will decide which type is correct. The other choice of type is incorrect.

In some languages, these things are blurred because the language doesn’t let you choose a correct type for the state space, but I’m talking about the case where you can (coincidentally the set of languages I’d use).

[coin]

Null is the absence of a value. How do to distinguish 0 from no value?

[Maxatar]

The point is to eliminate the idea of an absence of a value. A variable is always assigned to a value, but there is a special value called null which behaves as a kind of sentinel value whose methods all return the null value for their respective type.