{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreicjptxykhpe72ixqh77ngqdrhlrceguqliojuwxb4xp6bvx4xmkwa",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mgji7yflhqc2"
  },
  "path": "/t/idea-pre-rfc-null-free-pointer-and-zeroable-reference/23991?page=6#post_107",
  "publishedAt": "2026-03-07T22:33:54.000Z",
  "site": "https://internals.rust-lang.org",
  "textContent": "H4n_uL:\n\n> doesn't that confirm the gap has to be closed below the library level?\n\nThat's why I proposed those two functions as additions to the standard library earlier. I think having `read`/`write`/`copy` and `copy_non_overlapping` variants in `core` would make sense. But anything more complex that that belongs in a third-party crate.\n\nThey are not strictly necessary, since `read_volatile` works. But that sacrifices performance and `const`.\n\nH4n_uL:\n\n> `Cell` exists to _hide_ references behind interior mutability;\n\n`Cell`'s purpose is to enable shared single threaded mutability. It will become much more useful once you can manipulate individual fields of a struct.\n\nThe benefits for `MaybeUninit` are smaller, but there are no soundness issues with projecting a `&mut MaybeUninit<Struct>` to a `&mut MaybeUninit<Field>` either.\n\nH4n_uL:\n\n> Without field projection, it doesn't become verbose; it fails to be what it is.\n\nVerbose field projection can be implemented in a library already. So native field projection is only an ergonomics improvement.",
  "title": "Idea / Pre-RFC: Null-free pointer and Zeroable reference"
}