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.

[heaths]

Seems there was some discussion in 2020 about univariant enums. What I cant find is if there was ever a discussion - or, better, a decision - on supporting #[repr(transparent)] on bivariant enums with an empty variant like Result<(), u32> or similar to cover FFI-compatible scenarios. @gnzlbg I see your moniker related to a lot of this discussion. Do you know? From the aforementioned issue, I didn't see any follow-up since 2019 about an RFC. Is that still needed?

[scottmcm]

@heaths It's unclear to me what you expect transparent on a multi-variant enum like Result<(), u32> is supposed to mean -- that type is 64 bits as it needs a discriminant and the payload. Did you mean something where one of the arms is impossible, like Result<u32, !>?

[heaths]

I see your point. Perhaps this is overly optimizing for a specific use case - FFI - but since my (and others') intention was to define native functions returning non-zero errors, would constraints make it easier to discriminate e.g. Result<(), std::num::NonZeroU32>?

[scottmcm]

@heaths That's a niche optimization question, so you're probably looking for a different issue -- it's definitely not a "single-variant enum", even if it might layout-optimize down to 32 bits.

[heaths]

I ran across rust-lang/rust#84277 as well, which eventually - hopefully - is a way to solve this seemingly common FFI scenario. I agree it's a niche optimization, though.

[scottmcm]

@heaths Yes, that exact FFI scenario is written out specifically in the RFC: https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#implementing-try-for-a-non-generic-type

[digama0]

@heaths By the way, from this exchange I think there might have been a miscommunication: @scottmcm means it's a (niche optimization) question, not a niche (optimization question). That is, it's a question about niche-optimization (that is, efficient bit-packing of enums where the variants disallow some range of values), not a question about optimizations which are "niche" i.e. applicable only to a restricted set of scenarios.

[pnkfelix]

Discussed at T-opsem backlog bonanza.

This is T-lang, not opsem

@rustbot label: +T-lang +S-not-opsem