Flag proposal
Nick Sabalausky
a at a.a
Sun Jun 12 12:26:25 PDT 2011
"Timon Gehr" <timon.gehr at gmx.ch> wrote in message
news:it0oee$ehu$1 at digitalmars.com...
> 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!
>
Not only that, but just simply trying to explain why you sometimes do
"enumName.value" and sometimes do "value.enumName". It introduces a big
inconsistency for callers, just for the sake of a trivial decrease in
boilerplate for the callee.
Also, one thing I'm unclear on:
If you do:
void foo(Flag!"bar" a) {}
Can the caller do something like this?:
bar barValue = yes.bar;
foo(barValue);
More information about the Digitalmars-d
mailing list