Transparent Unions and Enums

[mjbshaw]

Let's allow #[repr(transparent)] on unions and univariant enums that have exactly one non-zero-sized field (just like structs).

Rendered.
Tracking issue: rust-lang/rust#60405

_{Pre-RFC Discourse discussion on internals.rust-lang.org.}

[mjbshaw]

Thanks for the review, @Centril! I'm still working on getting to those last remaining items you mentioned, but in the meantime I implemented the feature (including for univariant enums). It probably needs some fixing, and definitely needs some tests, but it can serve as a starting point for what the feature might look like in real life.

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[gnzlbg]

FWIW I consider that use case a very long stretch of our imagination about what this RFC could be useful for.

We explored many use-cases for a long time on Discord, and all of them could be solved by just guaranteeing the layout of these unions.

The Rust-Rust C FFI dynamic library case was what we invented to justify this, but you need to control Rust code at both sides to make it work, and if that's the case, why aren't you using the Rust ABI ? There might be good arguments for that, but I would prefer if this RFC was put on hold until we merge an RFC guaranteeing layout for these types first, and then see what value would this add on top of that.

[hanna-kruppe]

@gnzlbg The Rust calling convention is unstable, so the C calling convention (or others not defined by rustc) are your only choice if you want to link together two pieces of Rust compiled with different compiler versions. Most Rust types don't have a stable ABI either, so you can't use them in those interfaces, but MaybeUninit could be one of the types that work just fine there. (Of course, making is repr(C) would also achieve that, but as we discussed there will be cases where ABI transparency is desirable.)

[Centril]

There might be good arguments for that, but I would prefer if this RFC was put on hold until we merge an RFC guaranteeing layout for these types first, and then see what value would this add on top of that.

@gnzlbg Note that if/when this RFC is merged the actual implementation will go through the usual stabilization process. If you want to file an RFC you will have plenty of time to do so.

[gnzlbg]

two pieces of Rust compiled with different compiler versions.

@rkruppe my point was that for the Rust-Rust dynamic lib over C FFI to work you kind of have to been in control of the Rust code on both places to make sure they make use over the right Rust types (if they only assume the code at the other side of the ABI is C then none of this applies).

That is, if you are in control of the Rust code at both sides, you can often compile it with the same compiler version. Sure, this is not always the case, but it feels like if.. if.. if.. if.. then this is useful, which is what i mean by a stretch.

[vi]

Shall this be allowed?:

#[repr(transparent)]
enum StaringIntoTheVoid {
   Empty(!),
   Lifeline(i32),
   DoublyNothing(!,!),
}

What is interaction between #[repr(transparent)] and the never_type?

[mjbshaw]

@vi Interesting, I hadn't thought of that case. Currently the plan is to allow only single-variant enums to be transparent, so that wouldn't be allowed in the current plan. I think we could safely allow that in the future if desired (though I wouldn't pursue it without a good answer to how we should handle it if we changed the code to DoublyNothing(u8,!)).

[vi]

though I wouldn't pursue it without a good answer to how we should handle it if we changed the code to DoublyNothing(u8,!)

Obviously, the same as DoublyNothing(!,!) or std::convert::Infallible or other uninhabited type.

[Centril]

I think a consistent handling would look for singleton enums rather than "univariant" (i.e. semantic rather than syntactic approach). A semantic approach would make StaringIntoTheVoid legal. However, no one is going to realistically write StaringIntoTheVoid so I can't say I care unless consistency simplifies the definition/implementation.

[vi]

However, no one is going to realistically write ...

Macros and code generation may write such and other redundant things. Both #[repr(transparent)] and the uninhabited type may arrive though some macros or have associated #[cfg] trickery. Sometimes the enum would have two actual, inhabited variants, sometimes it would morph into a transparent wrapper around someting else. Using ! to delete enum's variant from within may be useful for macros/codegen.

[mjbshaw]

My issue with enumerations like StaringIntoTheVoid are that:

• Rust doesn't currently recognize that DoublyNothing(u8,!) can be optimized out of the type, so supporting this would require more work.
• It's unclear how this should interact with private never fields. For example, if struct Never(!); is defined in an external module, should the enumeration be allowed to be transparent if it uses Never instead of !?

I'm not opposed to these types of enums being transparent-able, but I think there are some open questions about how much work it is to do it and exactly what should and shouldn't be allowed.

[eddyb]

Rust doesn't currently recognize that DoublyNothing(u8,!) can be optimized out of the type, so supporting this would require more work.

We had that optimized for a while and it was actually a bug (rust-lang/rust#49298).

[vi]

I assumed it is indended that a singe ! cascades though all tuples and structures, only stopping at enum variant.

Are partially initialized structures officialy OK per unsafe guidelines? Is this code guranteed?:

#![feature(maybe_uninit,never_type,maybe_uninit_ref)] 
#![allow(dead_code)]

use std::mem::MaybeUninit;

struct A { b:!, c:i32 }

fn main() {
    let mut a  : MaybeUninit<A> = MaybeUninit::uninitialized();
    unsafe { a.get_mut().c = 5; }
    println!("{}", unsafe { a.get_ref().c } );
}

If yes then it makes ! just a fancy ZST instead of actual zero type.

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

The RFC will be merged soon.

[gnzlbg]

Note that the second example:

It is also useful for consuming pointers to uninitialized memory:

works without this feature, since it only requires layout compatibility, and not repr(transparent).

[gnzlbg]

I have a dumb question, is

#[repr(transparent)] union<T> U { t: T, u: () }

ok?

What happens if I write U<()> (the union only contains ZSTs)? What ABI is picked, and how does behave in extern "C" ? Or do I get a compiler error saying that repr(transparent) unions cannot contain ZSTs ? (maybe that would be a killer for MaybeUninit ).

[hanna-kruppe]

FWIW with structs that is allowed, and S<()> just ends up being a ZST and is passed as such. That makes it not/barely suitable for C FFI, but ultimately that's up to the user (and the improper_ctypes lint). It's also not really substantially different from the same example without a second () field (i.e., just a generic newtype without any extra ZSTs), which should also be allowed.

[Centril]

Huzzah! This RFC has been merged!

Tracking issue: rust-lang/rust#60405

(Please excuse the delay!)

[RalfJung]

Looks like there might be a use-case after all for by-value MaybeUninit in FFI?