On 6/10/11 3:36 PM, Nick Sabalausky wrote:
"Nick Sabalausky"<a@a.a> wrote in message
news:istv62$2skn$1...@digitalmars.com...
"Andrei Alexandrescu"<seewebsiteforem...@erdani.org> wrote in message
news:isttf6$2oub$1...@digitalmars.com...
On 6/10/11 1:52 PM, Robert Clipsham wrote:
foo(param: true, otherParam: false);
foo(Flag!"param".yes, Flag!"otherParam".no);
I don't know about you, but I find the former is far more legible. I'd
hate to see my code littered with Flag!"something".
I agree it's more legible. The crucial question is whether the added
legibility warrants adding a new feature to the language.
I really see Flag more as a way to try to rationalize avoiding adding
named parameters to the language.
And yes, the legibility of "foo(Flag!"param".yes, Flag!"otherParam".no);",
combined with the frequency of need for such a thing, and the complete
inability of Flag to address the problem for anything but bool, the
inability to document it separately (as Jonathan Davis pointed out), is
all definitely much much more than enough to warrant adding a
tried-and-proven feature that's become standard in damn near every other
modern language.
Regarding "the complete inability of Flag to address the problem for
anything but bool", how are we going to wind up papering over that?
Like:
box(Int!"x"(3), Int!"y"(4), Int!"width"(100), Int!"height"(150),
Int!"depth"(1), UInt!"color"(0xFFAA77));
?
I don't find it entirely fair to demean the suggestion as a tool to
sustain your viewpoint.
Flag supporting only yes and no is not a "complete inability" - it is
its charter. The plan is not to have Flag be a replacement for named
arguments, but instead to have it support good practices for Boolean
settings and replace a number of awkward enum definitions in Phobos.
As I mentioned, in the future it's possible to have Flag (or a related
abstraction) support categorical features beyond yes and no, but it is
not meant, and does not attempt, to cover named arguments.
Andrei
