What is the value model/validity invariant for single-field transparent unions?

[alercah]

As we have discovered with #[repr(C)] in #156, the bag-o-bytes value model does not survive contact with the ABI. This also poses a problem for #[repr(transparent)] unions. This has been discussed on the RFC 2645 tracking issue for transparent unions: rust-lang/rust#60405. But I think we should track this conversation at the UCG as well.

We appear to be constrained to support arbitrary byte patterns for unions that have at least one ZST, however, because you can always do U{zst: /*val*/} in Safe Rust to get a fully uninitialized value of the union. But we could support niches for single-field transparent unions.

[RalfJung]

The model I implemented in MiniRust is that a union is a "bag of bytes with gaps": there are ranges of bytes whose values are preserved, and there can be gaps between those ranges to model the presence of padding.

That refine bag-o-bytes model does survive contact with reality I think, and we can use it for all unions, transparent or not.

[RalfJung]

Also I think this issue is mixing up single-field unions and transparent unions -- MaybeUninit is a repr(transparent) union, and clearly cannot have a niche. So really the title should be about single-field unions. repr(transparent) alone is not special.

[alercah]

Yes, sorry, I was in a hurry when writing this. You're quite right about the title; I will update it accordingly.

I think the refined bag-o-bytes model works fine, but at the cost of Option<TransparentUnion<T>> being ABI-incompatible with Option<T>. I do not know whether this is something there is any desire to support, but since it has come up a lot in the conversation around RFC 2645, it deserves to be answered intentionally I think.

[alercah]

I'm of the opinion that the value model should not be special for transparent unions: they should act the same regardless of the presence or absence of a ZST field.

Conditioning on the existence of such a field is extremely unintuitive, and would require that they be a completely separate, special value model among unions.

Rust already has a way to create ABI-compatible newtypes: a struct (or single-variant enum) with #[repr(transparent)].

[RalfJung]

I think the refined bag-o-bytes model works fine, but at the cost of Option<TransparentUnion> being ABI-incompatible with Option. I do not know whether this is something there is any desire to support, but since it has come up a lot in the conversation around RFC 2645, it deserves to be answered intentionally I think.

Personally I think that's fine, we already don't have Option<UnsafeCell<T>> being ABI-compatible with Option<T> and this is similar.