Flag proposal

Steven Schveighoffer schveiguy at yahoo.com
Sat Jun 11 06:05:52 PDT 2011


On Fri, 10 Jun 2011 19:16:14 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

> On 6/10/11 6:03 PM, Dmitry Olshansky wrote:
>> On 11.06.2011 0:58, Andrei Alexandrescu wrote:
>>> On 6/10/11 3:30 PM, Nick Sabalausky wrote:
>>>> I really see Flag more as a way to try to rationalize avoiding adding
>>>> named
>>>> parameters to the language.
>>>
>>> There are fights that I believe are important and others that I think
>>> are less so. I find name parameters nice to have but more in the
>>> second category. There's just so much stuff that's more important.
>>>
>>>> And yes, the legibility of "foo(Flag!"param".yes,
>>>> Flag!"otherParam".no);",
>>>
>>> Fair point. I figured this should be easier:
>>>
>>> foo(yes!"param", no!"otherParam");
>>
>> I think this looks not half bad and does not require change in the
>> language.
>> Still yes.param and no.param might be easier on the eyes, though IMO it
>> should look more like just param and no.param.
>> e.g.
>> StopWatch(autoStart);
>> StopWatch(no!autoStart); // or no.autoStart
>
> Ask, and ye shall receive.
>
> https://github.com/andralex/phobos/commit/801ccc96ce56827cd0d0b608895269bdccba4330

This is better.  Does the definition of the function still require  
repetition?  i.e. getLine(Flag!"KeepTerminator" keepTerminator =  
Yes.KeepTerminator).  I suppose we can live with that.

Still reads weird to me with the value coming before the category, but I  
suppose the names can be adjusted accordingly.

As far as the negation, I think we need one more layer of type:

struct FlagParam(string pname)
{
    Flag!pname value;
    alias value this;
    this(Flag!pname x) { this.value = x }
    FlagParam op???() const { return FlagParam(cast(Flag!pname)!value); }
}

BTW, is there a way to hook "!"?  Maybe this won't work...  The idea is to  
have Yes.abc return FlagParam!"abc"(Flag!"abc".yes).

-Steve


More information about the Digitalmars-d mailing list