There is a difference between an API promissing that a value wont be null and a buggy program setting a null where it should not. A reference is only null if someone fucked up. As a programmer you can usually rely on a reference not being null and you couldn't do anything about it if it was anyway within the constraints of the language.

In the same way, an `enum class` variable's value being outside of the set defined in the `enum class` is also a fuckup.

no, deferencing a null ptr is UB. An enum class outside the declared values is perfectly valid.

You could design a language feature where integer to enum is checked, but that's not enum.

Enum classes already add scoping, forbid implicit conversions and allow explicit underlying types. Those are pure extensions. Making undeclared values invalid or UB would be very surprising to people used to normal enums.

And you can also open /proc/self/mem in a Rust program and overwrite whatever you want, including pointers. So?

One of those cases happens accidentally all the time (in more complex variants than the motivating example you responded to), the other never happens except on purpose. It's like complaining guard rails are pointless because people being launched with catapults might still fly over them and plunge to their deaths.

I've never seen a nullptr somehow sneak into a reference. Never.

What I have seen is automatic variables escaping their scope as a reference, which rust protects against. And is also much more dangerous, because dereferencing a nullptr is defined behavior on most platforms