On 4/8/14, 12:56 PM, Andrei Alexandrescu wrote:
> On 4/8/14, 12:54 PM, Steven Schveighoffer wrote:
>> On Tue, 08 Apr 2014 15:51:31 -0400, Andrei Alexandrescu
>> <SeeWebsiteForEmail@erdani.org> wrote:
>>
>>> On 4/8/14, 12:23 PM, Steven Schveighoffer wrote:
>>>> What about allowing enum methods?
>>>
>>> No because CTFE. -- Andrei
>>
>> What about what I said is prevented by or prevents CTFE (not sure what
>> your objection is)?
>
> CTFE renders enum methods unnecessary. -- Andrei

Wrong term - UFCS. -- Andrei

On Tue, 08 Apr 2014 15:57:31 -0400, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> On 4/8/14, 12:56 PM, Andrei Alexandrescu wrote:
>> On 4/8/14, 12:54 PM, Steven Schveighoffer wrote:
>>> On Tue, 08 Apr 2014 15:51:31 -0400, Andrei Alexandrescu
>>> <SeeWebsiteForEmail@erdani.org> wrote:
>>>
>>>> On 4/8/14, 12:23 PM, Steven Schveighoffer wrote:
>>>>> What about allowing enum methods?
>>>>
>>>> No because CTFE. -- Andrei
>>>
>>> What about what I said is prevented by or prevents CTFE (not sure what
>>> your objection is)?
>>
>> CTFE renders enum methods unnecessary. -- Andrei
>
> Wrong term - UFCS. -- Andrei
>

OK, that makes more sense :)

So the idea was to eliminate enum operations, except for what was defined in the enum itself. A kind of way to dictate via code the operations that make sense for that enum set.

So this goes with a way to disable all operations that normally are accepted (except equality).

-Steve

6. An integral type, some of which have names:

enum Color {
    Red = 0xFF0000,
    Green = 0x00FF00,
    Blue = 0x0000FF00,
    Fred = 0x123456,
    White = 0xFFFFFF }

On Tuesday, 8 April 2014 at 21:12:10 UTC, Walter Bright wrote:
> 6. An integral type, some of which have names:
>
> enum Color {
>     Red = 0xFF0000,
>     Green = 0x00FF00,
>     Blue = 0x0000FF00,
>     Fred = 0x123456,
>     White = 0xFFFFFF }

This is not an integral type but collection of named constants with shared qualified path. Probably most common use case and one that should not have been part of enum design but a separate concept.

On 4/8/2014 2:16 PM, Dicebot wrote:
> On Tuesday, 8 April 2014 at 21:12:10 UTC, Walter Bright wrote:
>> 6. An integral type, some of which have names:
>>
>> enum Color {
>>     Red = 0xFF0000,
>>     Green = 0x00FF00,
>>     Blue = 0x0000FF00,
>>     Fred = 0x123456,
>>     White = 0xFFFFFF }
>
> This is not an integral type but collection of named constants with shared
> qualified path. Probably most common use case and one that should not have been
> part of enum design but a separate concept.

The thing is, I want to be able to name that type:

    void setColor(Color newcolor) { ... }

Having a bunch of named constants doesn't do that.

On Tuesday, 8 April 2014 at 21:21:22 UTC, Walter Bright wrote:
> On 4/8/2014 2:16 PM, Dicebot wrote:
>> On Tuesday, 8 April 2014 at 21:12:10 UTC, Walter Bright wrote:
>>> 6. An integral type, some of which have names:
>>>
>>> enum Color {
>>>    Red = 0xFF0000,
>>>    Green = 0x00FF00,
>>>    Blue = 0x0000FF00,
>>>    Fred = 0x123456,
>>>    White = 0xFFFFFF }
>>
>> This is not an integral type but collection of named constants with shared
>> qualified path. Probably most common use case and one that should not have been
>> part of enum design but a separate concept.
>
> The thing is, I want to be able to name that type:
>
>     void setColor(Color newcolor) { ... }
>
> Having a bunch of named constants doesn't do that.

With current D type system this gives you pretty much nothing over `(uint newcolor)`. Still can have any integral value.

On Tuesday, 8 April 2014 at 19:09:55 UTC, Andrei Alexandrescu wrote:
> 1. Is the current design damaging enough (= allows enough wrong/buggy code to pass through) to warrant a breaking tightening?

Enums in D *should* be tightened to be at least type-safe, but I don't think it's a large issue.

> 2. To what extent can library-based approaches help?

You could consider it an embarrassment that we should need a library solution to cover up for (arguably) bad design in the language. Speaking pragmatically, though, it looks like library solutions could possibly take us quite far.

> 3. What is the priority of improving enums in the larger picture of other things we must do?

Enums could stand to be improved, but finishing the implementation of the language should take precedent. Figuring out scope (which Adam Ruppe had some good ideas for) and shared is what instantly comes to mind... These are probably also the two hardest tasks remaining. Then there's also making objects default non-null, tuple syntax, qualified constructors...

On Tue, 08 Apr 2014 17:12:17 -0400, Walter Bright <newshound2@digitalmars.com> wrote:

> 6. An integral type, some of which have names:
>
> enum Color {
>      Red = 0xFF0000,
>      Green = 0x00FF00,
>      Blue = 0x0000FF00,
>      Fred = 0x123456,
>      White = 0xFFFFFF }

That was Andrei's UserId example...

On Tue, 08 Apr 2014 15:08:46 -0400, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> 3. A discrete set of categorical values, not all of which are named:
>  enum UserID : ulong { nobody, expired = ulong.max }

-Steve

On Tuesday, 8 April 2014 at 19:09:55 UTC, Andrei Alexandrescu wrote:
> 1. Is the current design damaging enough (= allows enough wrong/buggy code to pass through) to warrant a breaking tightening?

No.

> 2. To what extent can library-based approaches help?

Depends on how specific compilers can optimise all the aggregate type boilerplate away. Potentially a lot, though in somewhat ugly way.

> 3. What is the priority of improving enums in the larger picture of other things we must do?

Very low in my opinion, compared to other issues.

On 4/8/2014 2:45 PM, Dicebot wrote:
> With current D type system this gives you pretty much nothing over `(uint
> newcolor)`. Still can have any integral value.

Not true. It gives:

1. overloading
2. symbolic debug info
3. cannot implicitly convert to Color
4. .min and .max properties
5. a scope for the member names
6. ddoc info