Flag proposal

[so]

> 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

(Trying the 3rd time, something wrong with newsreader)

As you might know i prefer library solutions to language changes any day  
even the change is additive, yet this one i don't like.
Library solutions, especially those affect user must be IMO both elegant  
and generic, this one is not. I think we are agree on this.

There might be 7 in only std.algorithm but it is after all belongs to the  
std library, with the importance of phobos we can't change anything that  
is not accepted by majority. These are i think pretty strong arguments,  
though i believe it is you that needs to come up with strong arguments and  
i can't see any from you either :)

Introducing an idiom to phobos means it is the D way, there should be many  
other frameworks that would use such a solution much more frequently. They  
will either dismiss this solution (most likely) or populate it. The former  
means the failure of the change, the latter is ugly code (again, when it  
is used more frequently).

Named arguments both clean and generic.
On one drawback (?) that variable names being part of library definition,  
i don't see how it is a drawback.