enum

[Jonathan M Davis]

On Friday, April 11, 2014 08:22:01 Steven Schveighoffer wrote:
> On Thu, 10 Apr 2014 15:22:35 -0400, Andrei Alexandrescu
> 
> <SeeWebsiteForEmail at erdani.org> wrote:
> > On 4/9/14, 9:47 PM, Walter Bright wrote:
> >> On 4/9/2014 5:39 PM, Jonathan M Davis wrote:
> >>> On Wednesday, April 09, 2014 14:14:21 Andrei Alexandrescu wrote:
> >>>> One wants to call a function taking such an enum. -- Andrei
> >>> 
> >>> But it _isn't_ going to be a valid enum value. IMHO, a function which
> >>> is
> >>> taking or-ed flags where those flags are enums needs to take uint or
> >>> ulong or
> >>> whatever the base type of the enum is and _not_ the enum type.
> >> 
> >> It makes perfect sense if you think of an enum as an integral type, some
> >> values of which have names, as in the "Color" example I posted earlier.
> > 
> > Problem is you think of it like that in a subset of cases only. FWIW I
> > wouldn't have advocated for final switch if that was the fostered view.
> 
> Idea just came to me. What about notifying the compiler which enums can be
> used in final switches (and perhaps should be more stringent in allowing
> math operations):
> 
> final enum name { ... }

This only makes sense to me if it's then illegal to declare any variables of 
that enum type, because if you're looking to use an enum to give a list of 
possible values rather than enumerating the exact list of values, why would 
you be marking _any_ variable as being of that enum type? In that case, it's 
just a list of predefined values with names associated with them, and

enum Color : uint { red = 0xFF0000, green = 0x00FF00, blue = 0x0000FF }

isn't much different from

struct Color
{
 enum uint red = 0xFF0000;
 enum uint green = 0x00FF00;
 enum uint blue = 0x0000FF;
}

You're just looking for a way to have the variables be grouped together so 
that you're typing Color.red or Color.green instead of just red or green. It's 
expected in that case that other, unlisted colors can and will be used (e.g. 
0xFD07AB), and so using the type Color for a variable doesn't even make sense. 
It's not really a type. Rather, it's a grouping of values for an existing type 
that have been given meaningful names so that your code is clearer. And why 
would it make sense to use a new type for variables if all you're doing is 
introducing a list of predefined values with handy names?

And if that's the case, then you're not going to be declaring any variables of 
type Color - just using the values in Color to assign to ints that represent 
the color. And whether you can assign other values to a variable of type Color 
or not is irrelevant, because it would never be being used as a type. As such, 
having enum's be fully restrictive so that all operations on them which aren't 
guaranteed to result in a valid enum value instead results in the enum's base 
type wouldn't affect them. They'd just happily implicitly convert to the base 
type whenever they're used, because you'd just be using the base type for the 
variables. You wouldn't declare variables of the enum type, and you wouldn't 
use final switch.

So, as far as I can see, the only thing that something like final enum would 
buy you would be if we then made it so that it was illegal to declare 
variables of non-final enums, since it doesn't make sense to do so. IMHO, 
regardless of whether we add final enum or not, it makes no sense for enum 
variables not to be protected against ever becoming invalid enum values 
without casting, because it makes no sense to use enum variables if you just 
want a list of constants rather than an enumeration.

- Jonathan M Davis