this is almost a workaround for the lack of named parameters

[John Colvin]

On Friday, 22 March 2013 at 20:04:14 UTC, foobar wrote:
> On Friday, 22 March 2013 at 10:17:02 UTC, J wrote:
>> With credit for inspiration to David Medlock in this post-- 
>> http://forum.dlang.org/thread/d9lnrr$26q3$1@digitaldaemon.com 
>> ...
>>
>> // Tongue firmly in cheek, I'd like to introduce
>> // the NAPAPISS principle: (with apologies to SFINAE and RAII)
>>
>> // NAPAPISS = NAmed Parameters Are simply Passed in a Struct, 
>> Silly.
>>
>> // Yes, indeed, maybe this is what happens after drinking too 
>> much of
>> // the fine wine products from the Napa valley... you start 
>> having
>> // wild flights of fancy of how D might surprisingly soon have
>> // named parameters....
>>
>>
>> import std.stdio;
>> import std.c.stdlib;
>>
>> void main(string[] arg) {
>>
>>    // this works today: but with the drawback that the
>>    // named params must be known at compile time...
>>
>>    // Here is a named param call,
>>    // as compact as I could get it (see struct below for 
>> actual definition).
>>
>>    auto a = myfunc!q{ z= 2; x = -123; y = 200 }(0)(); // calls 
>> opCall
>>    writeln("a=", a); // prints "a=yo", as returned from opCall
>>
>>
>>
>>    // And here's the runtime version, unfortunately you have to
>>    // pre-declare g because otherwise it won't survive the 
>> scope, and
>>    // the return value from myfunc.opCall would become 
>> inaccessible.
>>    string g;
>>    with(myfunc!()(0)) {
>>          x=rand() % 40;
>>          y=x/2;
>>          z=y/2;
>>          g = call(); // as a side effect, prints 'X 7, Y 3, Z 
>> 1'
>>     }
>>     writeln("g=", g); // prints "g=yo", as returned from opCall
>>
>>
>> /*
>>    // The bright future: this demonstrates that
>>    // it would be fairly trivial to make some kind of 
>> annotation
>>    // like @kwarg or whaterver, to indicate that a function
>>    // was using this calling convention:
>>    @kwarg string f(int a, string b) { body; }
>>
>>    // so that @kwarg function definitions are lowered to:
>>    struct f_kw {
>>      int a;
>>      string b;
>>      string f() { body; }
>>    }
>>
>>    // and calls to @kwarg functions are transformed
>>    // from this:
>>    auto r = f(a=5, b="good");
>>
>>    // into this:
>>    f_kw tmp34;
>>    tmp34.a = 5;
>>    tmp34.b = "good";
>>    auto r = tmp34.f();
>>
>>    // the benefit: named parameters can be used in a natural 
>> way,
>>    // and they need be known only at runtime.
>> */
>> }
>>
>> // how the 'works today' above examples were implemented:
>> struct myfunc(string init_string="")
>> {
>>   // named keyword or named parameters
>>   // --the call arguments and their defaults
>>   int x=0;
>>   int y=0;
>>   int z=0;
>>
>>   this(int) {}
>>   string opCall() {
>>     mixin(init_string ~ ";");
>>     writefln("X %s, Y %s, Z %s", x, y, z );
>>     return "yo";
>>   }
>>   alias opCall call;
>> }
>>
>>
>> On Friday, 22 March 2013 at 09:18:33 UTC, J wrote:
>>>
>>> The bigger point here is more profound: it is trivial to 
>>> implement named parameters using structs + trivial lowerings, 
>>> and this is no way conflicts with function overloading.
>>>
>>> D deserves to have named parameters to functions -- it makes 
>>> for much more legible code, and obviates the need for slow 
>>> builder patterns.  Readable and speedable. It's win-win.
>
> WTF? What do kwargs have to do with programming? Sounds more 
> like a half-Klingon & half-Ferengi species to me.

kwargs = keyword arguments

It's a common naming convention in python, as exemplified in 
matplotlib.