Validity of enum variants with #[repr(...)] #[non_exhaustive]

[TyPR124]

Take, for example

#[repr(u8)]
#[non_exhaustive]
enum Enum {
    Zero,
    One,
}

fn is_this_safe() -> Enum {
    unsafe { std::mem::transmute(2u8) }
}

I believe https://rust-lang.github.io/unsafe-code-guidelines/layout/enums.html explains well enough that this enum will be u8-sized, and will have variants Zero=0 and One=1. However, does adding #[non_exhaustive] make other bit-representations of this type valid? Similar questions for other kinds of (non-fieldless) enums.

Also, does #[non_exhaustive] have any affect on the rules around "option-like enums" and "niche" values?

[RalfJung]

However, does adding #[non_exhaustive] make other bit-representations of this type valid? Similar questions for other kinds of (non-fieldless) enums.

Also, does #[non_exhaustive] have any affect on the rules around "option-like enums" and "niche" values?

No. #[non_exhaustive] only affects type checking, but it has no effect at all on niches, validity, or UB.

That is the current status, anyway.

[TyPR124]

Thanks, I figured it was unlikely to change validity (or layout), but it could be good to make this explicit (and relax it later if it ever changes). Someone could (with misguided logic) think any value is valid since any match will always include a catch-all arm.

I could add a note to the enum layout page, or add a (likely short) page on enum validity if you want.

[hanna-kruppe]

Someone could (with misguided logic) think any value is valid since any match will always include a catch-all arm.

Note that matches in the crate (or module? not sure) defining the non-exhaustive type don't need the catch-all arm. Perhaps this is the "misguided logic" you refer to but I want to make sure we're all on the same page.

[TyPR124]

Note that matches in the crate (or module? not sure) defining the non-exhaustive type don't need the catch-all arm

I was not aware of this. I'm pretty sure this is the first I've ever heard that non_exhaustive behaves differently in different contexts. I did start with the language well before non_exhaustive was stabilized so it if wasn't mentioned specifically in release notes then I probably never would have known this until I found out the hard way somehow.

Still, I feel like if I had the thought that it could maybe affect validity, I have to assume someone else will think the same at some point.

I used "misguided" mostly in the sense that you can come to a logical conclusion that doesn't match reality. Although in this specific case having a fuller knowledge of non_exhaustive would have invalidated that logic anyway.

[RalfJung]

I could add a note to the enum layout page

It probably makes sense to explicitly say this when discussing niches etc, yes. If you could prepare a PR, that would be great. :)

or add a (likely short) page on enum validity if you want.

Such a page doesn't exist yet; #69 is where we discuss what should go onto that page. Can you leave a comment there?

[RalfJung]

I think this question has been answered / recorded in the relevant issue #69.