Enums should magically get a trait for getting `discriminant` and `variant_count`

[quinedot]

@user16251

There are times when it's convenient to think of them as having multiple variants and it seems like declaring their variant counts to be one might prevent block some changes in the future.

How would declaring their variant counts to be #{distinctValues} be any less blocking of other concepts?

In it's current form, variant_count can't return the number of possible values of

• u32 and above on 16 bit systems
• u64 and above on 32 bit systems
• u128 on 64 bit systems
• Many non-integers

How would you resolve that?

[jrose]

Another example:

#[repr(transparent)]
struct MyWeekday(DayOfWeek);

MyWeekday is supposed to have the same ABI as DayOfWeek here because of repr(transparent), and yet I’d still be surprised if this had a variant count of 7 rather than 1. I’m sure there are others who think differently, and that’s how we end up with the behavior on non-enums remaining unspecified.

[idanarye]

@quinedot

In it's current form, variant_count can't return the number of possible values of

• u32 and above on 16 bit systems
• u64 and above on 32 bit systems
• u128 on 64 bit systems

The number of possible values for u32 cannot be represented even in 32 bit systems, and the number of possible values for u64 cannot be represented even in 64 bit systems. AFAIK there are no 128 bit systems yet, but once we get there the number of possible values for u128> won't be representable there.

Because these types need to represent the zero, the maximum number they can represent is lower by one than the number of values they can represent.

[user16251]

I'd rather variant_count not be defined for fundamental types at all.