Out of all of those options, I’d probably be equally happy with tag-only enum, scalar enum, integral enum, or enum without fields. So I’m not sure how well a poll that only lets you choose one option will work for this.
I’m also not sure if I should be explaining why I like the others less when we don’t even know who the “finalists” are yet, so I’ll just pick on a few that I think no one else picked on yet: I mildly dislike “trivial enum” and “degenerate enum” because to me those terms would imply a zero-variant enum (following their typical usage in math). I also mildly dislike “flat enum” because I think a non-flat enum would be an enum whose type definition contains some rightward drift/curly brace nesting; to me an enum where every variant carries a u8 is just as flat as an enum where no variants carry anything (perhaps it’s taller or fatter, but it’s equally flat).
The point of the poll is to select the finalists. I’d probably want to take something like the top 5 and then vote between those (basically, an elimination election). However, since I have no actual position on the core team, nothing here is binding.
Also, I thought about allowing multiple choices, but decided it didn’t actually matter. If you don’t vote for it, someone else will.
I think it kind of implies that every tag only has a single tag as opposed to more ADTish enums where every constructor can represent more than one value.
In my code I don’t use enums to represent C enums. I use constants. That way I decide what happens if I get a constant I don’t recognise (usually panic but not always). I think bindgen are doing this now. C enums are implementation defined.
For what it’s worth, the original intent for #[repr(C)] was to match the base type that a C compiler for the same target would use for a corresponding C enum, assuming that explicitly ABI-breaking flags like -fshort-enums are not used. (This actually predates #[repr(C)] for structs.) I spent some time going through ABI specs when I was writing the original discriminant size selection to try to ensure that would hold for the targets that were supported at the time, but it might not have been kept up-to-date.
As for the problem with impossible values: yes, that’s a problem. Maybe #[repr(C)] was never the right way to handle this, but that’s a topic for another thread.
In any case, I agree that “C-like” is a bad way to describe this just because it’s opaque to people who don’t know C.
I’ve already gone with pull requests to try “field-less enum,” but if one of these gets overwhelmingly more votes than any others, then I’d rather go with that.