On 04/11/2014 12:07 PM, Walter Bright wrote:
>
> The point being that D is powerful enough that you can use structs and
> templates to create all kinds of types with custom behaviors.

Not including the kind of type whose expressions can be used in a final switch.

On Friday, 11 April 2014 at 10:07:13 UTC, Walter Bright wrote:
> The point being that D is powerful enough that you can use structs and templates to create all kinds of types with custom behaviors. They don't all need to be baked into the core language.

Yes, but it supports enum as a separate kind of types - but there are two fundamental different usages of enums, for which a totaly different set of operations is required:
1: "real" enums, that enumerate all possible values, that can be used in final switch and that shouldn't allow for any kind of arithmetic performed on them - not even increment (maybe a enum count, but thats all)
2: types with some named constants, that should NOT be usable in final switch but provide arithmetic, discontinual values and everything what enum at the moment falsely provides.

So, D need not provide enums (both kinds can be build from structs) but if it does, it should not unify them in ONE type. There are too different expectations to enums as that one type can satisfy them all. --> add a new type ("partial_enum" or whatever) that can be used with arithmetics like flag-arrays or COLOR, _and_ forbid the arithmetics for real enums.

On Thu, 10 Apr 2014 15:22:35 -0400, Andrei Alexandrescu <SeeWebsiteForEmail@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 { ... }

-Steve

On Friday, 11 April 2014 at 12:21:59 UTC, Steven Schveighoffer wrote:

> 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 { ... }
>
Yes, this is a good name for the new type.
"enum" and "final enum" make a better pair than "partial_enum" and "enum" as I have suggested.

On 4/11/14, 5:22 AM, Steven Schveighoffer wrote:
> On Thu, 10 Apr 2014 15:22:35 -0400, Andrei Alexandrescu
> <SeeWebsiteForEmail@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 { ... }
>
> -Steve

This is a most interesting idea! -- Andrei

On 4/11/2014 4:18 AM, Jonathan M Davis wrote:
> I don't see much point to enums if they're not intended to list
> all of their values.

Again, bit masks, Color, etc., and to provide a simple integral type that behaves like an integral type yet can be overloaded and type checked.

Andrei has pointed out that these uses are unsound if you desire that the enumeration lists all possible values, and he's right. But I don't think that automatically makes them pointless.

Heck, look at the "StorageClass" typedef in dmd's source code, and the list of STC macro definitions. That would make a nice D enum, and have some type safety too. It would be much more sound than the C method used.

Am 11.04.2014 20:32, schrieb Walter Bright:
> On 4/11/2014 4:18 AM, Jonathan M Davis wrote:
>> I don't see much point to enums if they're not intended to list
>> all of their values.
>
> Again, bit masks, Color, etc., and to provide a simple integral type
> that behaves like an integral type yet can be overloaded and type checked.
>
> Andrei has pointed out that these uses are unsound if you desire that
> the enumeration lists all possible values, and he's right. But I don't
> think that automatically makes them pointless.
>
> Heck, look at the "StorageClass" typedef in dmd's source code, and the
> list of STC macro definitions. That would make a nice D enum, and have
> some type safety too. It would be much more sound than the C method used.

Sure, but aren't those use cases a consequence of C's misuse of enums, which are handled better by numeric constants?

--
Paulo

On Friday, April 11, 2014 08:22:01 Steven Schveighoffer wrote:
> On Thu, 10 Apr 2014 15:22:35 -0400, Andrei Alexandrescu
> 
> <SeeWebsiteForEmail@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

On Friday, 11 April 2014 at 12:13:20 UTC, Dominikus Dittes Scherkl wrote:
> Yes, but it supports enum as a separate kind of types - but there are two fundamental different usages of enums, for which a totaly different set of operations is required:
> 1: "real" enums, that enumerate all possible values, that can be used in final switch and that shouldn't allow for any kind of arithmetic performed on them - not even increment (maybe a enum count, but thats all)
> 2: types with some named constants, that should NOT be usable in final switch but provide arithmetic, discontinual values and everything what enum at the moment falsely provides.
>
> So, D need not provide enums (both kinds can be build from structs) but if it does, it should not unify them in ONE type. There are too different expectations to enums as that one type can satisfy them all. --> add a new type ("partial_enum" or whatever) that can be used with arithmetics like flag-arrays or COLOR, _and_ forbid the arithmetics for real enums.

No the first kind need language support, for thing like final switches.

Good now we have one that need language support and one that can be built as library. We are at the same point as 5 pages ago, let's bikeshched again for 50 pages and decide nothing now.

On Friday, 11 April 2014 at 12:21:59 UTC, Steven Schveighoffer wrote:
> 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 { ... }
>
> -Steve

I unerstand what you are trying to do here. You are solving a political problem, with a solution that is inferior (but won't require anyone to be proven wrong, so that have greater chance to be accepted).

The problem is that is increase language complexity, plus make the most common use case of enum nit the most direct, obvious one. It is going to break every single piece of code that use final switch. And the default behavior of enum still remain a useless 3 headed monster, that could be created as a library solution, and that nobody really want anyway.

No.