Flag proposal

[Andrei Alexandrescu]

On 06/11/2011 04:42 PM, Jonathan M Davis wrote:
> On 2011-06-11 14:32, David Nadlinger wrote:
>> On 6/11/11 11:20 PM, Jonathan M Davis wrote:
>>> 1. Programmers following this idiom (including the Phobos devs) end up
>>> creating enums with yes and no values and are effectively identical to
>>> other enums except for their names. So, we end up with a fair bit of
>>> boilerplate code just to pass a strict boolean value.
>>
>> s/fair/tiny/, imho:
>>
>> ---
>> /// ditto.
>> enum SomeFlag { enable, disable }
>> ---
>
> It's a fair bit only insomuch as the same code is duplicated in several
> places. The code itself in each instance is small. But if you do that enough
> times, it adds up. Whether it's enough to matter is debatable, but there is
> definitely boilerplate code there which could be reduced.
>
> - Jonathan M Davis

It's the namespace pollution and the non-self-containedness of the 
function that's most troublesome. Also see Steve's point about methods. 
It's just untenable - to use the idiom with a class/struct method, you 
need to go all the way _outside_ of it an plant a symbol there.

What I find most interesting is that the lack of strong counterarguments 
has not stood in the way of a strong emotional response. This mood has 
made it difficult for exchange of rational arguments. Funny thing is, 
the change is tiny.

"Here, I'll add a handful of yes/no enums here and there in the standard 
library, just to help some algorithms. More to come."

"Yeah, sure, whatevs."

"Here, there's a way to define them once so we don't need to define them 
everywhere."

"Gaaaaaaaaaaaaaa!!!"


Andrei