"Timon Gehr" <timon.g...@gmx.ch> wrote in message news:it0oee$ehu$1...@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);