Flag proposal

[Nick Sabalausky]

"Andrei Alexandrescu" <SeeWebsiteForEmail at erdani.org> wrote in message 
news:it1cd7$1vv2$1 at digitalmars.com...
> 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 like the basic idea, and it's a change that falls into the "removing 
restrictions" category.

But the issue "so" brought up with this about not being able to pass in a 
variable would need to be solved for the general case. It's trivial in the 
case of two options:

   bool useSorted = ...;
   someAlgorithm(..., useSorted? sorted : unsorted);

Although, really, that just shifts the boilerplate from the callee to the 
caller, so it's really a net loss.

You could maybe do:

   T someAlgorithm(..., enum Sorted {yes, no} sortOutput);

Which would be equivalent to:

   enum Sorted {yes, no}
   T someAlgorithm(..., Sorted sortOutput);

But I don't now if Andrei would like that (it makes the func signature kinda 
verbose, too).

>
> 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.
>

Your Flag idiom essentially defines a type in a function parameter 
specification.