Why is Option<(u64, u32)> larger than Option<(u64, u32, NonZeroU32)>?

[sbarral]

On 64-bit architecture I would expect both to be 16 bytes since they both leave a niche for the Option bit, but Option<(u64, u32)> counter-intuitively turns out to be larger at 24 bytes wide, why is this?
Is it a good idea to add a dummy NonZeroU32 field to make the Option smaller or is there some downside to this (assuming again a 64-bit architecture)?

[alice]

Padding is allowed to have any value, so there is no niche in (u64, u32).

And the size of (u64, 32) must be 16 rather than 12 because the alignment is 8 and the size must be a multiple of the alignment.

[sbarral]

thank you, I see.
Yes, the reasons for 16 bytes were clear to me, I just though that padding could be used for the niche.

For those looking for a longer discussion:

Why does a bigger type become the smaller one when wrapped in Option?

(Sorry, if the title is kinda confusing.) #![allow(unused)] struct Normal { a: u32, b: u16, } struct Padded { a: u32, b: u16, _padding: bool, } fn main() { assert_eq!(std::mem::size_of::<Normal>(), 8); assert_eq!(std::mem::size_of::<Option<Normal>>(), 12); assert_eq!(std::mem::size_of::<Padded>(), 8); assert_eq!(std::mem::size_of::<Option<Padded>>(), 8); } Rust somehow prefers to add 6 more bytes to Normal when wrapping it in an Option rather than just ad…

[alice]

I wouldn't add a NonZeroU32 to the tuple because it would be confusing. If the size is important, then I would rather create a struct with the three fields and clearly document what the purpose of the NonZeroU32 is using field names and documentation.

I might use this type instead of NonZeroU32:

/// A type that can be used in place of padding
/// in a struct or tuple to give the padding a niche
/// for the Option optimization.
#[repr(u32)]
enum PaddingWithNiche {
    Padding = 1
}

[sbarral]

Many thanks!
Actually my use-case was indeed for a struct with private fields, I just mentioned tuples for conciseness of the question.

[binarycat]

@alice

Padding is allowed to have any value

do you happen to have a source for that? i'd like to dig into the specifics of rust layout guarantees, but i'm not able to find the relevant section of the rust reference.

[quinedot]

When does copying an uninitialized byte poison the destination?

https://rust-lang.github.io/unsafe-code-guidelines/glossary.html#padding