Flag proposal

[Andrei Alexandrescu]

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