On 06/11/2011 04:58 PM, Timon Gehr wrote:
Jonathan M Davis wrote:
...
The complaints about this generally seem to be one of these:
1. Dislike of the yes/no enum idiom in the first place. Regardless of how Flag
does it, it's a problem, because it's promoting an idiom that the poster
dislikes in the first place.
2. Flag!"enumName".yes and Flag!"enumName".no are ugly.
3. The use of a template such as Flag results in ugly error messages when it's
mistyped. EnumName.yes gets _much_ better errors when mistyped than
Flag!"enumName".yes.
4. Flag is seen as a narrow attempt at named arguments which would be far
better served by actually implementing named arguments.
[snip.]
5. The approach is too sophisticated and does not pull its own weight.
Imagine what you would have to explain to somebody new to the language who
wondered how Yes.sortOutput works... instant turn-off!
What about allowing anonymous enums in parameter lists? Unfortunately that would
be a language feature. :)
T someAlgorithm(..., enum {unsorted, sorted} sortOutput);
To call: someAlgorithm(..., sorted); / someAlgorithm(..., unsorted);
I proposed this to Walter some years ago, around the time I was
anticipating the nascent yes/no enum proliferation. The problem with
this is it defines a type in a function parameter specification, which
is unprecedented and therefore surprising.
There's a closely related slide in our D 2007 conference talk.
Andrei
