External Publication
Visit Post

Dereferenceable Zero

Rust Internals [Unofficial] March 15, 2026
Source

Thank you for raising some concerns, I genuinely appreciate it and will address each point.

R081n:

In the type mapping section how do you make sure lifetimes are obeyed when mapping between the new &T and *const T?

The 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.

R081n:

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.

To clarify: it is not a matter of reinterpretion. It is like seding with rustfix. New-edition's Option<@T> is always 1-word-wide and Option<&T> is always 2-words-wide. They are separate types.

If I have any missing point, I'd welcome to engage.

R081n:

Where do you save the extra word of the Option<&T>. after all:

Yeah that got me, I'll fix the description.

Discussion in the ATmosphere

Loading comments...