On Fri, 10 Jun 2011 19:16:14 -0400, Andrei Alexandrescu
<seewebsiteforem...@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
