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