{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreifeigi2pwbkqwpxhstrzakic7grvg76djf6fu5d3fwnoc7eoxx6de",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mgk4eqojqr72"
  },
  "path": "/t/idea-pre-rfc-null-free-pointer-and-zeroable-reference/23991?page=6#post_106",
  "publishedAt": "2026-03-07T22:18:31.000Z",
  "site": "https://internals.rust-lang.org",
  "tags": [
    "rust#138351"
  ],
  "textContent": "Fair, I withdraw the UB concern here; the remaining concerns still stand.\n\nCodesInChaos:\n\n> `Cell` and `MaybeUninit` don't have field projection support either, and those are _much_ more common.\n\n`Cell` exists to _hide_ references behind interior mutability; `MaybeUninit` exists to _hide_ uninitialised memory. Field projection is a nice-to-have feature, or even a soundness hazard for them - their purpose is fulfilled without field projection or aided by its absence. A zeroable reference is the opposite - transparent access to fields _is_ its entire purpose. Without field projection, it doesn't become verbose; it fails to be what it is.\n\nAnd looking at `replace_memory` in your `any_mem` sketch, that's the operation `ptr::replace` couldn't do soundly because it relies on `&mut *dst` internally (rust#138351). Your playground itself annotates `read_memory`/`write_memory` as \"needs compiler magic\" - doesn't that confirm the gap has to be closed below the library level?",
  "title": "Idea / Pre-RFC: Null-free pointer and Zeroable reference"
}