Added Flag template

[andralex]

In order to make Phobos calls self-explanatory, we have a lot of small enums defining "no" and "yes". This request systematizes that approach by making it easy to use such flags without needing to define them. Furthermore, code outside Phobos can define and use flags of their own.

[andralex]

Acted on suggestions.

[andralex]

I must add this makes me particularly proud of eliminating parens from one-argument templates :o).

[dnadlinger]

I'm not really sure what to think about this – not that the implementation wouldn't be nice, but in my opinion, introducing named parameters would be the better solution to this problem. I vaguely recall a discussion on the topic, was there any reason for not adopting them? Even C# has them now, and in my eyes they would make a hell lot of sense for D as well…

[jmdavis]

It's a bit more verbose than the current solution (e.g. Flag!"KeepTerminator".yes rather than KeepTerminator.yes), which I don't particularly like, but it does eliminate a fair bit of small bits of boilerplate code. It also standardizes this particular design pattern a bit, which is nice. Overall, I'm in favor.

As for named arguments, this can work with them just fine, though if we get named arguments at a later date and decide that we want to switch everything to bool, then we can just switch everything over then. Doing this now will reduce the boilerplate code in Phobos and encourage the use of this particular design pattern.

[michelf]

I find it a little surprising to see something named "Flag" be simply a boolean in disguise. I'd have expected it to be more generic, something letting you to put multiple flags in a single value for instance, as you can find in many APIs.

Also, I agree with klickverbot: named parameters would be much better for this. The goal seems to be to compensate for a lack of expressiveness in the language, but this solution being limited to booleans and having a redundancy at the definition site (Flag!"Name" name) makes it look as if something is missing. And there's also the issue that everywhere you use it you need to name the parameter type Flag!"Name", which is just ugly. It's a clever hack for sure, but not something I'd tell people to use in regular circumstances.

[andralex]

Michel: it's "flag", not "flags". I'll answer the other point in the newsgroup.

[dnadlinger]

If this goes in, we really need to do something about the quality of error messages:

void foo(Flag!"bar" bar, Flag!"baz" baz) {}

void main() {
  foo(Yes.bar, No.bar);
}

Error: function foo (Flag bar, Flag baz) is not callable using argument types (Flag,Flag)
Error: cannot implicitly convert expression (opDispatch()) of type Flag to Flag

[andralex]

Good point. Once the compiler improves these messages, other cases will be improved too.

[andralex]

Too controversial.