Flag proposal

Jonathan M Davis jmdavisProg at gmx.com
Fri Jun 10 14:08:29 PDT 2011


On 2011-06-10 13:36, Nick Sabalausky wrote:
> "Nick Sabalausky" <a at a.a> wrote in message
> news:istv62$2skn$1 at digitalmars.com...
> 
> > "Andrei Alexandrescu" <SeeWebsiteForEmail at erdani.org> wrote in message
> > news:isttf6$2oub$1 at 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


More information about the Digitalmars-d mailing list