#[repr(u16)] enum doesn't pack fields as expected

[upsuper]

The following code:

#[repr(u16)] enum Foo { A, B(u32, u16) }
println!("{}", std::mem::size_of::<Foo>());

currently outputs 12, but Foo really only needs to take 8 bytes.

There are several alternatives which can correctly be packed into 8 bytes:

#[repr(u8)] enum Foo { A, B(u32, u16) }

#[repr(u16)] enum Foo { A, B(u16, u32) }

I see no reason why the first enum couldn't be packed into 8 bytes.

[Robbepop]

I have similar code that requires an enum to be properly sized (pointer sized) due to performance constraints.
I would like for my code not to be dependent on a hack to circumvent a bug. 🙃
Where do I need to go or look in order to fix this bug? Or is it actually a "hard problem" which explains why it is still open since 2018?

[hanna-kruppe]

repr(Int) enums have a guaranteed memory layout which means the discriminant must come first and the fields of each variant must be laid out in source code order. Together with typical (not guaranteed I think) 4-byte-aligned u32, that layout forces the enum to be 12 bytes when the first field of the B variant is u32, but not when the u16 field comes first. Note that all of this also applies to the repr(u8) version with B(u32, u16) in the original issue description. Either the reporter was mistaken about that one or something changed since 2018.

This should not affect equivalent enums without any repr(…) annotation. A quick test on the playground seems to confirm that it’s 8 bytes without repr (but of course you don’t get any layout guarantees in that case). If you have a counter-example, please share it.

[Robbepop]

@hanna-kruppe Thank you a lot for the clarification!

If this behavior is guaranteed and it indeed is not a bug I am fine with that outcome. Also we probably should close this issue to avoid confusion.