Proposal + Bikeshed: Rename C-like Enumeration

[FaultyRAM]

A few ideas from me:

• Tag-only enumerations
• Trivial enumerations
• Plain enumerations

[retep998]

#[repr(C)] discriminant only enums are not necessarily the same size as the equivalent C enum. Even when they are the same size, holding any value other than the defined variants is UB, unlike the equivalent C enums which are often used as bitflags. Using Rust enums in FFI bindings is generally a bad idea.

Therefore I am strongly in favor of moving away from the “c-like enum” terminology.

[QuietMisdreavus]

We had a quick chat about this idea at today’s docs-team meeting. Of the suggestions so far, we seem to like either “plain/simple enums” or “data-less enums”/“enums without fields”. The latter is pertinent because it was mainly proposed in terms of removing the need for a fancy name altogether. Enums are enums; some have fields and some do not. The ability to set numerical values to the discriminant in these enums is just a property of not having fields. (Or “data”, or whatever we’ve decided the general term for values other than the discriminant enclosed in an enum variant is.)

So, i guess, the options we’re narrowing it down to are:

• “simple enums”, as a subset of “enums”
• “enums with fields/data” as opposed to “enums without fields/data” (with “field-less”/“data-less” as a shorthand)

If it were strictly between those two, what would you pick?

[rkruppe]

+1 for “enums without fields”

[sunjay]

Maybe “name-only” or “enums without fields”?

[jesskay]

“data-less”/“field-less” (and their longer forms where more appropriate) strikes the ideal balance for me - it’s simpler and shorter, without needing the reader to figure out what “simple” actually implies (not that it’s a particularly hard one to figure out with minor context, but it still seems slightly worse than the term which outright says what it means)

[bstrie]

Why does this even need an official name at all? We don’t call enums that benefit from NonZero “nonzero enums”; Rust does all sorts of enum optimizations under the hood, why privilege this one?

If we must call it something, avoid jargon like “discriminant” at all costs. “Simple enums” would suffice.

[Havvy]

I personally avoid terms like “simple” and “plain” to describe anything because they aren’t really self-describing. Granted, that’s an improvement over a misleading name.

We want a name for it because they interact with other features (e.g. casting to integers) in ways that enums with data do not. They need at least one variant because those without variants are called zero-variant enums, and want to avoid creating inheretance hierachies in names.

[ciphergoth]

+1 to “flat enumeration” or “flat enum”

[notriddle]

Instead of saying “+1,” let’s use an actual poll:

• simple enum
• degenerate enum
• flat enum
• discriminant-only enum
• numeric enum
• scalar enum
• integral enum
• variant-only enum
• immediate enum
• trivial enum
• tag-only enum
• plain enum
• field-less enum (enum without fields)
• data-less enum (enum without data)
• c-like enum

Show results

[Witolve]

+1 for c -like enum, though i see that only the first few have some votes gotta go now because i need to check the site. said i need to take bcuz of my health problems. but i will come back with some questions. about some of them. could you help??

[Ixrec]

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).

[notriddle]

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.

[lehmacdj]

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.

[derekdreery]

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.

[notriddle]

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

[jld]

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.

[notriddle]

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

Show results

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.

[Havvy]

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

[system]

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