{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreiafy6q5bxznzcdljczfifdpyw5fpvgiookecbtvixk4psmvaej5i4",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mh4fd22ih7u2"
  },
  "path": "/t/dereferenceable-zero/23991?page=7#post_133",
  "publishedAt": "2026-03-15T10:36:33.000Z",
  "site": "https://internals.rust-lang.org",
  "tags": [
    "@T"
  ],
  "textContent": "Thank you for raising some concerns, I genuinely appreciate it and will address each point.\n\nR081n:\n\n> In the type mapping section how do you make sure lifetimes are obeyed when mapping between the new `&T` and `*const T`?\n\nThe lifetime loss in the `*const T` mapping is a known degradation at the cross-edition boundary. This follows the same pattern as `async fn`: Rust 2015 cannot define it, but can call 2018's async functions through `Future` - a degraded but functional interop. Old-edition code receiving `*const T` operates under old-edition unsafe rules, and these boundaries shrink as adoption increases. If full lifetime tracking at the boundary is needed, a `LifetimePtr<'a, T>` wrapper in core could bridge the gap, but I'd consider that a separate proposal.\n\nR081n:\n\n> How do you know which layout a `&Option<&T>` is? It can come from a field of either a `repr(rust)` or `repr(C)` struct. And I can create a `Vec<&Option<&T>>` with mixed layouts.\n\nTo clarify: it is not a matter of reinterpretion. It is like `sed`ing with `rustfix`. New-edition's `Option<@T>` is always 1-word-wide and `Option<&T>` is always 2-words-wide. They are separate types.\n\nIf I have any missing point, I'd welcome to engage.\n\nR081n:\n\n> Where do you save the extra word of the `Option<&T>`. after all:\n\nYeah that got me, I'll fix the description.",
  "title": "Dereferenceable Zero"
}