impl `ZeroableInOption` for all `Zeroable`?

[Rua]

Currently, Option<NonZeroI32> implements Zeroable, but Option<i32> does not. Would it be sound to implement ZeroableInOption for all Zeroable types? Since zero maps to None in a regular option, this would always produce a valid value wouldn't it?

[Lokathor]

The compiler doesn't guarantee that None has a tag value of 0 when it has a separately stored tag.

In practice, in current rust, i believe this is what would occur, but it would only be by coincidence, not a stability promise.

[eric-seppanen]

There is a guarantee that the representation of Option<NonZero*> will be the same size as the underlying integer.

That plus the fact that there is only one niche bit-pattern available would seem to assure that None is always 0.

[Lokathor]

I believe that's a separate guarantee from what Rua asked for.

• Option<NonZeroI32> has a zero bit pattern for None, and this is guaranteed.
• Option<i32> has a zero bit pattern in practice, but I don't know about any particular guarantees in this area.

[zachs18]

There is a guarantee that the representation of Option<NonZero*> will be the same size as the underlying integer.

That plus the fact that there is only one niche bit-pattern available would seem to assure that None is always 0.

Yes, NonZero* already implement ZeroableInOption, and so Option<NonZero*> implement Zeroable via this impl.

This issue is about other types like Option<i32> which don't have such a layout guarantee.

[RReverser]

No, this definitely wouldn't be sound since enum tags can be optimised by using nested niches too.

Consider what happens when you put such Option into another one and get Option<Option<i32>>. Then the resulting type is still 8 bytes - a tag and an integer - and the tag representations will be:

• Some(None) -> 0
• Some(Some(x)) -> 1
• None -> 2

If you were to mark Option<T> as Zeroable for any T: Zeroable transitively, then zero-filling Option<Option<i32>> would result in Some(None) instead of the expected None.