> There's nothing stopping a compiler from implementing Option<T> as a possibly-null reference when T is a pointer type, which would give you the same efficiency as having nulls in the language while making unchecked usage easy to catch at compile time.
Rust does exactly that for its Option<T> type. In fact, it automatically works for a certain category of enums, not just for built-in ones. For example, this type:
enum E<'r> {
A(&'r u64),
B,
}
has the same size as a pointer (because references are guaranteed to be non-null), as has this type:
enum F {
A(Box<u64>),
B,
}
where Box<u64> is an owning pointer to a value on the heap. Rust's Option type doesn't get any special treatment and is not built-in, instead it's implemented like this in the standard library:
Rust does exactly that for its Option<T> type. In fact, it automatically works for a certain category of enums, not just for built-in ones. For example, this type:
has the same size as a pointer (because references are guaranteed to be non-null), as has this type: where Box<u64> is an owning pointer to a value on the heap. Rust's Option type doesn't get any special treatment and is not built-in, instead it's implemented like this in the standard library: