On 2011-06-10 13:36, 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));
These yes/no enums _aren't_ named arguments. They're an attempt at creating new types where the values say what they are. The goal is primarily clarity, which named arguments arguably help with, but it's not quite the same thing. Without typedef (which is on its way out), you can't really do something like that with anything other than bool. Int!"y"(4) has to generate an int (unless you want to be forcing that all of these arguments be structs, which would be hideous), at which point it's purely documentation which the compiler has to optimize out. It's not doing the same thing as Flag at all. Andrei isn't trying to create general named arguments here. He's simply trying to create a cleaner way of generating enums with yes and no values and thus reduce boilerplate code. Having named arguments would create a similar effect, but the goal of this enum has nothing to do with named arguments beyond the fact that they have a similar effect. Its goal is to reduce boilerplate code. The net result of having the enums and Flag _is_ similar to named arguments for bool, but I don't believe that Andrei ever set down this path with the idea of creating named arguments. He effectively wanted a typedef for bool which was self-documenting. So, your suggestions of Int!"height(150) and the like are trying to do something very different (albeit somewhat related) to what Flag is trying to do. - Jonathan M Davis
