UB in Rust vs C

UB in Rust vs C

> but what exactly is being achieved by this (as compared to only declaring *dereferencing* an invalid reference an UB)?

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.