On Monday, 25 March 2013 at 16:03:38 UTC, Jacob Carlborg wrote:
[cut]
> Add basic support for named parameters.
>
> This will only allow to add the name of the parameter
> when calling a function. It doesn't not support passing
> the arguments out of order.
>
> All credit goes to Michel Fortin.

Interesting, the "doesn't not support passing the arguments out of order." can be seen either as a (temporary or not) implementation limitation OR as a feature.

The things to check is how this feature would work with optional parameters..

renoX

On 2013-03-26 10:31, renoX wrote:

> Interesting, the "doesn't not support passing the arguments out of
> order." can be seen either as a (temporary or not) implementation
> limitation OR as a feature.

I would guess it was easier. At least the change is very small. Smaller that I would have imagined.

> The things to check is how this feature would work with optional
> parameters..

Good point.

-- 
/Jacob Carlborg

On Tuesday, 26 March 2013 at 09:31:53 UTC, renoX wrote:
> The things to check is how this feature would work with optional parameters..

Another thing to check is whether there is enough information in the object files to link across separately compiled objects.

Correct me if I'm wrong, but I don't think object files include the names of struct fields, nor the names of argument parameters.

You might have to do what objective-C does, which is merge the parameter names into the name of the function.

On Tuesday, 26 March 2013 at 20:28:39 UTC, J wrote:
> On Tuesday, 26 March 2013 at 09:31:53 UTC, renoX wrote:
>> The things to check is how this feature would work with optional parameters..
>
> Another thing to check is whether there is enough information in the object files to link across separately compiled objects.
>
> Correct me if I'm wrong, but I don't think object files include the names of struct fields, nor the names of argument parameters.
>
> You might have to do what objective-C does, which is merge the parameter names into the name of the function.


Or maybe there are no link time issues.  If named parameters are only ever supplying additional type-check-time information, then there would be zero impact at link time. Correct?

On Tuesday, 26 March 2013 at 12:14:08 UTC, Jacob Carlborg wrote:
> On 2013-03-26 10:31, renoX wrote:
>
>> Interesting, the "doesn't not support passing the arguments out of
>> order." can be seen either as a (temporary or not) implementation
>> limitation OR as a feature.
>
> I would guess it was easier. At least the change is very small. Smaller that I would have imagined.
>
>> The things to check is how this feature would work with optional
>> parameters..
>
> Good point.

Tested this. Seems to work fine with optional parameters.

import std.stdio;
void test (int a, int b = 24, int c = 12, int d = 6, int e = 3)
{
  writeln(a);
  writeln(b);
  writeln(c);
  writeln(d);
  writeln(e);
}

void main ()
{
    test(a: 1,
            2,
         c: 9999);

}

// output:

$ ./namedarg_defaults
1
2
9999
6
3

>>Interesting, the "doesn't not support passing the arguments out of order." can be seen either as a (temporary or not) implementation >>limitation OR as a feature.

Named parameters are only interesting if we can skip some optional parameters.
This allows the python-like syntax of specifying only a subset of
parameters; otherwise this isn't very interesting. This is used
heavily in python and makes code
* self-documenting
* avoids DRY (don't specify unused params)
* avoids boilerplate of introducing auxiliary option structs and fields to it

Here are just 3 examples that hopefully will convince some that named params are useful and not ugly.

----
//inspired from python's matplotlib; many more options configurable, which are set to reasonable defaults plot(x=1,y=2,color='red',width=3);

//here's another one (cf inspired by scons / waf build tools in python)
compile(input=["foo.cpp"] , run=true, debug=true, ldflags="-lcurl",
output_dir="build");

//other example: setting optional params in a classifier
trainSVM(input=X, labels=Y, C=1000, crossValidate=true, loss=squareHingeLoss)
----

Additionally, we should be able to provide arguments out of order and
check at compile time that there are no duplicates and no unexistant
fields. The code i posted with support for
named!plot.x(2).color("red").width(3)
did that, and that wasn't hard. So hopefully it won't be easy to
support as well skipping, reordering and CT checking with @Michel
Fortin's shiny syntax.

Here are some design decisions to make: given a function void fun(int
a,int b=1, int c=2);

* whether to support mixing named and non-named arguments in 1 call
(python does)
fun(0,b=1)

* whether to allow both calling conventions:
fun(0,1)
fun(0,b=1)

* whether to allow both calling conventions:
fun(0,1)
fun(0,b=1)

* whether to tag functions callable by named params via attribute
(check is done at CT): that'll indicate clearly we want to freeze
names in the API
@named void fun(int a,int b=1, int c=2);

* alternatively to above, whether to use ':' instead of '=' in
function declaration
void fun(int a,int b:1, int c:2); //now it's only callable by name

* whether to support skipping and reordering optional args ; I argued we need to for this to be useful enough

Timothee Cour

On Wednesday, 27 March 2013 at 03:29:24 UTC, Timothee Cour wrote:
> Named parameters are only interesting if we can skip some optional parameters.
> This allows the python-like syntax of specifying only a subset of
> parameters; otherwise this isn't very interesting. This is used
> heavily in python and makes code
> * self-documenting
> * avoids DRY (don't specify unused params)
> * avoids boilerplate of introducing auxiliary option structs and fields to it
>
> Here are just 3 examples that hopefully will convince some that named
> params are useful and not ugly.
>
> ----
> //inspired from python's matplotlib; many more options configurable,
> which are set to reasonable defaults
> plot(x=1,y=2,color='red',width=3);
>
> //here's another one (cf inspired by scons / waf build tools in python)
> compile(input=["foo.cpp"] , run=true, debug=true, ldflags="-lcurl",
> output_dir="build");
>
> //other example: setting optional params in a classifier
> trainSVM(input=X, labels=Y, C=1000, crossValidate=true, loss=squareHingeLoss)
> ----

How is that any better than the monadic solution proposed in the thread and that dn't require any language addition ?

On Wednesday, 27 March 2013 at 03:29:24 UTC, Timothee Cour wrote:
>>>Interesting, the "doesn't not support passing the arguments out of order." can be seen either as a (temporary or not) implementation >>limitation OR as a feature.
>
> Named parameters are only interesting if we can skip some optional parameters.

I'd say named parameters are *more* interesting with skipping and re-ordering, but still incredibly valuable even without.  Let us get them in people's hands first (and start the addiction process going...bwahahaha!)

Let people experience first hand how awesome they are in a quick, doable form.

(Feel free to contribute code that implements those skipping and re-ordering features...)


Status update: I fixed the only known bug, and added a feature.

a. Named parameters now flow into variadic template arguments without a hitch.

In other words, this compiles:

void test(A...)(A a) {}
void main ()
{
    test(b: 33.3
         c: 44.4);
}


b. There is an name-matching escape mechanism now. It uses _underscores. If your function looks like:

void f(int a, int _b) {}

then you can call it like this:

f(a:1, anyLabelYouWant: 3);

(Actually this was necessitated by how dmd treats variadic actual arguments; it calls them _param_0, _param_1, ..., internally. I'm still going to call this escape-mechanism a feature, though.)


Here's the latest (see the named_parameters branch specifically)

https://github.com/glycerine/dmd/tree/named_parameters

This passes all tests.

Try it out. Try and break it.