this is almost a workaround for the lack of named parameters

J not_avail at notavailable.com
Fri Mar 22 03:17:01 PDT 2013


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.



More information about the Digitalmars-d mailing list