Layout of single-variant enums

[nikomatsakis]

Enums that contain a single variant and which do not have an
explicit #[repr] annotation are an important special case. Since
there is only a single variant, the enum must be instantiated with
that variant, which means that the enum is in fact equivalent to a
struct. The question then is to what extent we should guarantee
that the two share an equivalent layout, and also how to define the
interaction with uninhabited types.

As presently implemented, the compiler will use the same layout for
structs and for single variant enums (as long as they do not have a
#[repr] annotation that overrides that choice). So, for example, the
struct SomeStruct and the enum SomeEnum would have an equivalent
layout (playground)::

struct SomeStruct;
enum SomeEnum {
  SomeVariant,
}

Similarly, the struct SomeStruct and the enum SomeVariant in this
example would also be equivalent in their layout
(playground):

struct SomeStruct { x: u32 }
enum SomeEnum {
  SomeVariant { x: u32 },
}

In fact, the compiler will use this optimized layout even for enums
that define multiple variants, as long as all but one of the variants
is uninhabited
(playground):

struct SomeStruct { x: u32 }
enum SomeEnum {
  SomeVariant { x: u32 },
  UninhabitedVariant { y: Void },
}

[gnzlbg]

In fact, the compiler will use this optimized layout even for enums
that define multiple variants, as long as all but one of the variants
is uninhabited

We could resolve this with:

---

The layout of multi-variant enums with one inhabited variant is the same
as that of the single-variant enum containing that same inhabited variant.

For example, here:

struct SomeStruct { x: u32 }
enum SingleVariantDataCarrying {
    DataCarryingVariant(SomeStruct),
}
enum Void0 {}
enum Void1 {}
enum MultiVariantSingleInhabited {
  DataCarryingVariant(SomeStruct),
  Uninhabited0(Void0),
  Uninhabited1(Void1),
}

the layout of MultiVariantSingleInhabited is the same layout as that of
SingleVariantDataCarrying.

---

but doing so is blocked on resolving the layout of uninhabited types: #165 .

[hanna-kruppe]

That's not what is currently (or is planned to be) implemented, again because uninhabited types aren't all ZSTs and can be partially constructed. The plan of record is to only omit variants which are uninhabited and ZSTs.

[gnzlbg]

@rkruppe Makes sense. I think this might be then covered with a guarantee about layout for unions with a single (inhabited?) non-zero-sized field.

[RalfJung]

@rkruppe those issues apply to structs though, not to enums. Surface Rust does not allow partial initialization of enums. But maybe MIR does... in the spirit of rust-lang/rust#63616, I wonder what happens with something like

let x: Result<u32, (u32, !)> = Err((42, panic!()));

[hanna-kruppe]

Yes, that will have partial initialization in MIR. "Surface Rust allows partial initialization" was always just part of the story (and is even ruled out again right now!), the MIR-level motivation, specifically enabling aggressive move forwarding/emplacement without having to special case siblings of uninhabited places (to introduce fake temporary destinations), applies universally to structs, enums, and every other aggregate.