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).

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

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.

Yes - but as we keep repeating - if you do that why would you use null as a possible state to begin with? Not specific to Java, but in general.

E.g a boolean in java has two states true/false while a Boolean with capital B has 3 states true/false/null.

In that context you can choose type to represent how many states you have. E.g if it’s a field representing a cache of a bool value you can represent “not yet calculated” with null. It you were to magically convert null to false for a Boolean it only has two states! It’s now unusable for the purpose.

> The point is to eliminate the idea of an absence of a value

The whole point is to track the absence of a value. Why would one want to eliminate it?

null is way more trackable that some other special value like 0, -1, 999, "", etc.

You can do that with some types, but making 0 be that sentinel is completely bonkers.

You need a 257th value to have a byte sentinel.