Proposal + Bikeshed: Rename C-like Enumeration


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.

1 Like


I’d like to add constant enum to the bikeshed.

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.

1 Like


Just to mention why I picked field-less enum: it sounds like a description, instead of sounding like a made-up concept.



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.



Now we can go ahead and vote between the top four options.

  • field-less enum (enum without fields)
  • c-like enum
  • data-less enum (enum without data)
  • simple enum

0 voters

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.

1 Like


PRs changing C-like to Field-less have been written (mainly by notriddle) and accepted, except for my PR for the nomicon.

1 Like

closed #29

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.