this is almost a workaround for the lack of named parameters

[foobar]

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.