Idea / Pre-RFC: Null-free pointers

Thank you for the detailed response - I'll address each point.

RalfJung:

Both of your examples have UB, and would continue to have UB even if we allowed an allocation to exist at address 0. It is entirely pointless to try and ascribe any meaning to what happens when a program has UB.

You're right that observing what happens under UB is not a basis for argument, and that the examples in question involved dereferencing pointers without provenance. I've removed the section entirely - the case rests on the Need and significance section and the cost analysis below.

RalfJung:

It is about the underlying concept of an allocation in the Rust Abstract Machine (which includes heap allocations, stack allocations, and static allocations). This is necessarily a statement about the entire program, and currently, any part of a Rust program can assume for its own purposes that there is no valid allocation at address 0.

I understand that this is about the AM's concept of allocation, not the Allocator trait - I've removed ZeroableAllocator from the post accordingly. The deeper question you raise is that any Rust code today can rely on the invariant "no live allocation exists at address 0" for its own reasoning, e.g. using null as a sentinel to distinguish allocated from unallocated pointers. Changing this invariant would invalidate that reasoning.

I'd like to understand the scope of this: beyond &T/Option<&T> niche optimisations (which this proposal does not touch), is there existing code whose soundness proof - not convention - formally depends on the absence of a live allocation at address 0? If there are concrete examples, they would help assess whether a migration path exists. If the invariant is load-bearing in ways I haven't accounted for, I want to know.

That said - read_volatile and write_volatile on address 0 are already permitted, which means the AM already allows some operations to touch address 0 without triggering UB. The Vital change in this proposal extends that to non-volatile core::ptr operations. This is a wider scope, but not a jump from "0 is never touched" to "0 is fully valid" - it is a continuation of a direction the language has already taken.