enum

[Chad Joan]

On Tuesday, 8 April 2014 at 19:08:45 UTC, Andrei Alexandrescu 
wrote:
> (moving http://goo.gl/ZISWwN to this group)
>
> ...
>
>
> Andreiu

Honestly, my biggest issues with enums are name-qualification 
followed by stringizing.

When I say name-qualification, I mean this:
File myFile;
myFile.open("foobar.txt",
     FileAccess.READ |
     FileAccess.WRITE );

Things get long and start to wrap due to enums always requiring 
full name qualification.  This is a mild example; it gets worse 
pretty easily.

I'd much rather write:
File myFile;
myFile.open("foobar.txt", READ | WRITE );

It should be possible, because the argument's context is of the 
(hypothetical) FileAccess enum type.  It should be unambiguous 
that I intend to use FileAccess's "READ" symbol there, and not 
some other symbol from module scope.

I find myself using a module like this: 
http://dpaste.dzfl.pl/9b97c02a26fd
And writing my enums like this:

mixin dequalifyEnum!FileAccess;
mixin toStringifyFlags!FileAccess;
enum FileAccess : int
{
     READ  = (1 << 0),
     WRITE = (1 << 1),
}

It is essentially a reimplementation of the X-macro pattern from 
C, but using CTFE+mixins to accomplish the same thing in D.

It expands to something like this:

alias FileAccess.READ READ;
alias FileAccess.WRITE WRITE;
import std.exception : assumeUnique;
string toString(FileAccess val)
{
     char[] result = "FileAccess{".dup;

     if ( val & FileAccess.READ )
         result ~= "READ|";

     if ( val & FileAccess.WRITE )
         result ~= "WRITE|";

     if ( result[$-1] == '|' )
         result[$-1] = '}';
     else
         result ~= "}";

     return assumeUnique(result);
}
enum FileAccess : int
{
     READ  = (1 << 0),
     WRITE = (1 << 1),
}

I feel that this approach is bad, because it relies on the 
library writer to attach the goodies to the enum.  It also 
exposes the enum symbols at module-level, which seems icky to 
many people.  I still find it worthwhile because I dislike 
line-wrapping and can always disambiguate symbols by prepending 
the module name.

I feel like the following should happen:

File myFile;

// Fine!
myFile.open("foobar.txt", READ | WRITE );

// Fine!
myFile.open("foobar.txt",
    FileAccess.READ |
    FileAccess.WRITE );

// ERROR: READ is not accessible in this scope.
int someInteger = READ;

// Maybe OK, depending on how strict you want to be.
// It is fairly explicit, after all.
int someInteger = FileAccess.READ;

// Fine!  The enum's scope is inferred from context.
FileAccess someInteger = READ | WRITE;