{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreidtdpiaktuvyahjozemhmvio6s4bkx3q2udxwmzkcey4miufq2j2e",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mgmzoklbdk52"
  },
  "path": "/t/idea-pre-rfc-null-free-pointer-and-zeroable-reference/23991?page=6#post_114",
  "publishedAt": "2026-03-08T17:09:01.000Z",
  "site": "https://internals.rust-lang.org",
  "textContent": "The cost of your proposal, even in the best case, is an extra source of confusion for everyone dealing with raw pointers: when we are saying whether the raw pointer is dereferenceable / valid / whatever, do we allow for null or not? For backwards compatibility, we have to continue assuming that code is only robust against non-null dereferenceable pointers. That will have to be the default. But people will read documentation saying that actually accessing null pointers is fine, and then assume they are fine for crates that use the old terminology, and cause UB. This is a serious problem, it will cause UB bugs in real code. So the question is, can you demonstrate that the benefits outweigh this significant cost?\n\nSo far, I don't think you can. Field projections provide everything you need to build a suitable abstraction in library code. The ergonomics aren't perfect, but easily good enough for a niche usecase such as this. We don't accept RFCs on the off-chance that other RFCs (with significant momentum behind them!) don't make it, so your talk about \"weakest links\" doesn't support your RFC either. What remains is your claim that the missed optimizations caused by volatile accesses matter. So far this claim has not been substantiated with any evidence. You have _one_ example of code actually accessing address 0, and that code is apparently doing a big memcpy of some data from address 0x0 to non-volatile memory -- there's nothing to optimize here, a volatile memcpy will be just as fast as a regular one.\n\nH4n_uL:\n\n> the workaround it was forced into (inline assembly)\n\nThe work-around is volatile accesses. There is no need for inline assembly. You keep making incorrect claims even after their incorrectness has been pointed out to you. This is tiring. Maybe at the time said code was written, they had to use inline asm, but Rust has been improved in the mean time so it's disingenuous to keep bringing this up as an argument for further changes.\n\nYour OP also still talks about \"reference construction\" and \"slice creation\", despite it having been made unambiguously clear to you that those will never allow null.",
  "title": "Idea / Pre-RFC: Null-free pointer and Zeroable reference"
}