{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreiav5g3vhbdhcfjxhyykwf5nbhuiz7jj42mrtatjb3qndqx3kma5ai",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mgkjshhictj2"
  },
  "path": "/t/idea-pre-rfc-null-free-pointer-and-zeroable-reference/23991?page=6#post_105",
  "publishedAt": "2026-03-07T21:35:14.000Z",
  "site": "https://internals.rust-lang.org",
  "tags": [
    "playground"
  ],
  "textContent": "H4n_uL:\n\n> Relying on field projection and reborrow means this solution depends on two RFCs that are both still open experiments. If either changes direction or stalls, the entire library path disappears. This is the weakest link.\n\nThe library path doesn't disappear without these features, it just remains somewhat unergonomic.\n\nH4n_uL:\n\n> Also, ergonomics matters more than it might seem - `field_definition!(S, field_name)` + `*field!(&mut T, field_name)` vs `pointer.field` won't be a minor difference when you're working with dozens of struct fields.\n\nIt's a very exotic usecase, so I don't think that's a big deal if it's a bit verbose until rust adds native field projection support. `Cell` and `MaybeUninit` don't have field projection support either, and those are _much_ more common.\n\nH4n_uL:\n\n>\n>     impl GetField<Container, Field> for &'t Container {\n>\n>\n> This is an instant UB when ptr is 0x0.\n\nThat function doesn't receive a pointer, it receives a reference, which can't be null. That playground only demonstrates how field projections can work in stable rust, not how to handle usable null pointers.\n\nFor usable null pointers you'd need something like this playground",
  "title": "Idea / Pre-RFC: Null-free pointer and Zeroable reference"
}