UB in Rust vs C

Effective fix for the billion dollars mistake, essentially. References, in Rust, couldn't be null, attempting to create such a reference is an instant UB, but Option<&T> can hold None and, more importantly, it's guaranteed that in-memory representation for None in Option<&T> is the exact same thing as null in pointer and it's even guaranteed that it would be the same as null in pointer used by C on that platform!

That means that if you faithfully map nullable pointers to Option<&T> and non-nullable ones to &T then both Rust developers and Rust compiler would know what do you mean (if your function receives &T then you know that checks are not needed, object would be there, 100% guaranteed by the language, and if your function receives Option<&T> then you have to perform that check or else you couldn't dereference it, again language guarantees that).

That's really valuable property and to uphold it an attempt to push null into &T was declared “an instant UB”.

Note that currently even creation of non-null dangling reference is considered UB but that one is under intense debate: it enables some valuable optimizations, but that means that sometime you have to create valid objects from the “thin air”, etc. Before the final decision would be reached it's declared as “currently UB” because adding UB to the language is breaking change and removing it is not and and since it's not entirely clear why would someone need to create a dangling reference (most of the time you may just create a dummy object and pass around reference to that object when needed) it's kept as UB for now.

But that one is debated while attempting to shove null into reference just means you need Option<&T> in that place and it's better for everyone that you would just go and fix the code instead of begging for the dangerous (and pointless) changes to the language.

There's a theoretical reason, and a practical reason.

First, the theoretical reason: a reference has a validity constraint that it always, unconditionally, refers to a valid place. If you permit a reference to be "null", you now have to change the validity constraint to say that the reference either refers to a valid place, or is null; this is Hoare's "billion dollar mistake". There's a whole pile of things that pile up behind this change; it's not a trivial thing to do, since it affects the semantics of the entire language.

The practical reason is around optimization: if a reference must point to a valid place, then it's always OK to access the place it points to; that, in turn, means that you can write clear code, and have the compiler optimize it to the best code. It can, for example, change a conditional read of a reference to an unconditional read and a conditional use at all the places you had a conditional read, without having to consider the possibility that the conditional use was protecting against the reference being null. And because the compiler is aware of the memory model, it can issue the read much earlier, knowing that there are no memory accesses later in the function that can affect either where the reference points to, or what the value read can be.