Idea / Pre-RFC: Null-free pointer and Zeroable reference

H4n_uL:

I would take this concern seriously if it were backed by a concrete scenario. I made the same request in #83: if there is existing unsafe code whose soundness depends on the non-null assumption for raw pointers, I would appreciate a concrete example. (Does any existing code actually use "0x0 is UB, therefore unreachable" as part of its soundness proof?) This is not intended as pressure - I need concrete evidence to assess cost and risk.

You are the one who is proposing to change the language in subtle ways. The burden is on you to convince us that there is no significant risk here. I am informing you that I haven't been convinced yet (and reading the room, I think the same goes for a bunch of other project members).

H4n_uL:

I understand that perspective, but as noted earlier, in mission-critical engineering, depending on unstable features is not permitted. Having sufficient momentum is not the same as being stabilised, and even if field projection does land, I do not see how that constitutes grounds for rejecting this RFC.

Nobody said that unstable field projections are sufficient for you. But they will likely be stable eventually, and new feature proposal are expected to be evaluated against the language Rust will be, not just the language it is today.

If a feature that is already in development makes your motivation evaporate, then that's just not sufficient motivation. It makes zero sense to dismiss field projections here. We need to ensure that long-term , Rust remains a coherent well-rounded language, so of course we take into account ongoing experiments when new features are discussed.

This is not up for discussion, it is how the Rust project works. You will not make progress here if you keep pushing back against basic, well-established norms of the Rust community.

So, your motivation needs to make the case why a library type wrapping a raw pointer with field projections that internally uses volatile is not sufficient.