Cc @rust-lang/opsem

For thin pointer this seems perfectly fine, I am just not sure where to best document it.

I think for wide pointers, this is actually not true today (and seems unlikely to ever be true) -- the discriminant will be stored in one of the two "fields" of the pointer, which means that for None the other field is padding.

Sounds good. Put up a PR to guarantee this for thin pointers: #137323

In #115333, we added a guarantee that transmuting from [u8; N] to Option<P> is sound where P is a pointer type subject to the null pointer optimization (NPO).

No that's not what that PR did? It just talks specifically about transmuting [0u8; N], not arbitrary arrays of that type.

And similarly, looking at what you did in the new PR, it doesn't seem to match the issue description. The PR only guarantees that None::<P> can be transmuted to a u8 array and will yield a bunch of 0u8; it doesn't talk about e.g. transmuting Some(Box::new(i32)). That would be a ptr-to-int transmute so it is anyway tangled up in rust-lang/unsafe-code-guidelines#547.

In #115333, we added a guarantee that transmuting from [u8; N] to Option<P> is sound where P is a pointer type subject to the null pointer optimization (NPO).

No that's not what that PR did? It just talks specifically about transmuting [0u8; N], not arbitrary arrays of that type.

Good point; updated the issue text.

And similarly, looking at what you did in the new PR, it doesn't seem to match the issue description. The PR only guarantees that None::<P> can be transmuted to a u8 array and will yield a bunch of 0u8; it doesn't talk about e.g. transmuting Some(Box::new(i32)). That would be a ptr-to-int transmute so it is anyway tangled up in rust-lang/unsafe-code-guidelines#547.

Yeah, I realized the ptr-to-int issue and decided to stick with the more limited (and hopefully less controversial) None case.