www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Will D ever get optional named parameters?

reply =?UTF-8?B?IuWyqeWAiSDmvqoi?= <mio.iwakura gmail.com> writes:
 From what I've found, there was some work on this in the past 
(http://forum.dlang.org/thread/wokfqqbexazcguffwiif forum.dlang.org?page=6#post-thclpgdlfxxhhfklwsoj
40forum.dlang.org), 
but a pull request was never made/I don't seem to find discussion 
about adding it as a feature anywhere.

I think optional named parameters would be a nice addition, 
either to the core language, or something like the monadic 
solution from that old thread in phobos.

Are there good reasons not to add something like this to the 
language, or is it simply a matter of doing the work? Has it been 
discussed much?
Oct 13 2014
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/13/2014 1:29 AM, "岩倉 澪" wrote:

 Are there good reasons not to add something like this to the language, or is it
 simply a matter of doing the work? Has it been discussed much?


Named parameters interact badly with overloading.
Oct 13 2014
next sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Monday, 13 October 2014 at 08:48:11 UTC, Walter Bright wrote:

 On 10/13/2014 1:29 AM, "岩倉 澪" wrote:

 Are there good reasons not to add something like this to the 
 language, or is it
 simply a matter of doing the work? Has it been discussed much?


 Named parameters interact badly with overloading.


How so? Can't the overload just be calculated on the subset of 
arguments that are given?
Oct 13 2014
prev sibling next sibling parent =?UTF-8?B?IuWyqeWAiSDmvqoi?= <mio.iwakura gmail.com> writes:
On Monday, 13 October 2014 at 08:48:11 UTC, Walter Bright wrote:

 Named parameters interact badly with overloading.


Good point, I hadn't thought of that!
Oct 13 2014
prev sibling next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Monday, 13 October 2014 at 08:48:11 UTC, Walter Bright wrote:

 On 10/13/2014 1:29 AM, "岩倉 澪" wrote:

 Are there good reasons not to add something like this to the 
 language, or is it
 simply a matter of doing the work? Has it been discussed much?


 Named parameters interact badly with overloading.




--
Paulo
Oct 13 2014
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 13/10/14 10:47, Walter Bright wrote:


 Named parameters interact badly with overloading.


Nothing says that named parameters means that you can pass the arguments 
in any order. The linked forum post points to an implementation that 
requires the arguments to be passed in the regular order.

-- 
/Jacob Carlborg
Oct 13 2014
prev sibling next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
On 10/13/14, 5:47 AM, Walter Bright wrote:

 On 10/13/2014 1:29 AM, "岩倉 澪" wrote:

 Are there good reasons not to add something like this to the language,
 or is it
 simply a matter of doing the work? Has it been discussed much?


 Named parameters interact badly with overloading.


Could you give an example?
Oct 13 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/13/2014 7:23 AM, Ary Borenszweig wrote:

 On 10/13/14, 5:47 AM, Walter Bright wrote:

 On 10/13/2014 1:29 AM, "岩倉 澪" wrote:

 Are there good reasons not to add something like this to the language,
 or is it
 simply a matter of doing the work? Has it been discussed much?


 Named parameters interact badly with overloading.


 Could you give an example?


Nothing requires function overloads to use the same names in the same order for 
parameters. "color" can be the name for parameter 1 in one overload and for 
parameter 3 in another and not be there at all for a third.

Parameters need not be named in D:

    int foo(long);
    int foo(ulong x);

Named parameters are often desired so that default arguments need not be in 
order at the end:

    int foo(int x = 5, int y);
    int foo(int y, int z);

To deal with all this, a number of arbitrary rules will have to be created. 
Overloading is already fairly complex, with the implemented notions of partial 
ordering. Even if this could all be settled, is it worth it? Can anyone write a 
document explaining this to people? Do people really want pages and pages of 
specification for this?
Oct 13 2014
next sibling parent "Meta" <jared771 gmail.com> writes:
On Monday, 13 October 2014 at 19:18:39 UTC, Walter Bright wrote:

 Nothing requires function overloads to use the same names in 
 the same order for parameters. "color" can be the name for 
 parameter 1 in one overload and for parameter 3 in another and 
 not be there at all for a third.

 Parameters need not be named in D:

    int foo(long);
    int foo(ulong x);

 Named parameters are often desired so that default arguments 
 need not be in order at the end:

    int foo(int x = 5, int y);
    int foo(int y, int z);

 To deal with all this, a number of arbitrary rules will have to 
 be created. Overloading is already fairly complex, with the 
 implemented notions of partial ordering. Even if this could all 
 be settled, is it worth it? Can anyone write a document 
 explaining this to people? Do people really want pages and 
 pages of specification for this?


If you have several functions that take optional arguments, like 
the following:

int foo(bool b = false, int n, float f = 0.0f);
int foo(float n, bool b = false, float f = 0.0f);

foo(2, b: true);
foo(3.0f, f: 1.0f);

Wouldn't it only be necessary to overload on the non-optional 
arguments? Extending this, if a functional has only optional 
arguments, then there can only be one version of it.

int foo(int n = 0, bool b = false, float f = 0.0f);
//Error: cannot overload two functions with no non-optional 
parameters.
int foo(float n = 0.0f, bool b = false, float f = 0.0f);
Oct 13 2014
prev sibling next sibling parent "Cliff" <cliff.s.hudson gmail.com> writes:
On Monday, 13 October 2014 at 19:18:39 UTC, Walter Bright wrote:

 On 10/13/2014 7:23 AM, Ary Borenszweig wrote:

 On 10/13/14, 5:47 AM, Walter Bright wrote:

 On 10/13/2014 1:29 AM, "岩倉 澪" wrote:

 Are there good reasons not to add something like this to the 
 language,
 or is it
 simply a matter of doing the work? Has it been discussed 
 much?


 Named parameters interact badly with overloading.


 Could you give an example?


 Nothing requires function overloads to use the same names in 
 the same order for parameters. "color" can be the name for 
 parameter 1 in one overload and for parameter 3 in another and 
 not be there at all for a third.

 Parameters need not be named in D:

    int foo(long);
    int foo(ulong x);

 Named parameters are often desired so that default arguments 
 need not be in order at the end:

    int foo(int x = 5, int y);
    int foo(int y, int z);

 To deal with all this, a number of arbitrary rules will have to 
 be created. Overloading is already fairly complex, with the 
 implemented notions of partial ordering. Even if this could all 
 be settled, is it worth it? Can anyone write a document 
 explaining this to people? Do people really want pages and 
 pages of specification for this?


The only thing I like named parameters for is to avoid the 
following

foo(5 /* count */, true /* enableSpecialFunctionality */)

I like the documentation, but comments in the middle does feel 
cumbersome.  Tooling could add that automatically of course.  The 


foo(count: 5, enableSpecialFunctionality: true)

I don't care for or need the ability to reorder parameters, nor 
do I want additional rules to remember vis-a-vis overloading and 
optional parameters.  And I don't want a trivial name change in 
parameters to break my code - functions already have complete 
signatures, enforcing names just adds one more thing which could 
break people for no real benefit.

Sometimes I think features are proposed for the language which 
more rightly belong in tooling.
Oct 13 2014
prev sibling next sibling parent Shammah Chancellor <email domain.com> writes:
On 2014-10-13 19:18:38 +0000, Walter Bright said:


 On 10/13/2014 7:23 AM, Ary Borenszweig wrote:

 On 10/13/14, 5:47 AM, Walter Bright wrote:

 On 10/13/2014 1:29 AM, "岩倉 澪" wrote:

 Are there good reasons not to add something like this to the language,
 or is it
 simply a matter of doing the work? Has it been discussed much?


 
 Named parameters interact badly with overloading.


 
 Could you give an example?


 
 Nothing requires function overloads to use the same names in the same 
 order for parameters. "color" can be the name for parameter 1 in one 
 overload and for parameter 3 in another and not be there at all for a 
 third.
 
 Parameters need not be named in D:
 
     int foo(long);
     int foo(ulong x);
 
 Named parameters are often desired so that default arguments need not 
 be in order at the end:
 
     int foo(int x = 5, int y);
     int foo(int y, int z);
 
 To deal with all this, a number of arbitrary rules will have to be 
 created. Overloading is already fairly complex, with the implemented 
 notions of partial ordering. Even if this could all be settled, is it 
 worth it? Can anyone write a document explaining this to people? Do 
 people really want pages and pages of specification for this?



generates a warning and instead recommends providing more overloads.

-S.
Oct 13 2014
prev sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
On 10/13/14, 4:18 PM, Walter Bright wrote:

 On 10/13/2014 7:23 AM, Ary Borenszweig wrote:

 On 10/13/14, 5:47 AM, Walter Bright wrote:

 On 10/13/2014 1:29 AM, "岩倉 澪" wrote:

 Are there good reasons not to add something like this to the language,
 or is it
 simply a matter of doing the work? Has it been discussed much?


 Named parameters interact badly with overloading.


 Could you give an example?


 Nothing requires function overloads to use the same names in the same
 order for parameters. "color" can be the name for parameter 1 in one
 overload and for parameter 3 in another and not be there at all for a
 third.

 Parameters need not be named in D:

     int foo(long);
     int foo(ulong x);

 Named parameters are often desired so that default arguments need not be
 in order at the end:

     int foo(int x = 5, int y);
     int foo(int y, int z);

 To deal with all this, a number of arbitrary rules will have to be
 created. Overloading is already fairly complex, with the implemented
 notions of partial ordering. Even if this could all be settled, is it
 worth it? Can anyone write a document explaining this to people? Do
 people really want pages and pages of specification for this?


One simple thing we did in Crystal is to allow invoking a function with 
named arguments only for arguments that have a default value. For example:

void foo(int x, int y = 2, int z = 3) { ... }

foo(x, y: 10);
foo(x, y: 10, z: 20);
foo(x, z: 30)

But not this:

foo(x: 10)

The logic behind this is that named arguments are usually wanted when 
you want to replace one of the default values while keeping the others' 
defaults. You could specify names for arguments that don't have a 
default value, but that only gives a small readability aid. Changing a 
default value in the middle is a new feature.

This greatly simplifies the logic, since parameter reordering can only 
happen for names that have default values and you can always fill the 
gaps. Also, default values can also appear last in a function signature.
Oct 13 2014
parent reply =?UTF-8?B?IuWyqeWAiSDmvqoi?= <mio.iwakura gmail.com> writes:
On Tuesday, 14 October 2014 at 03:34:06 UTC, Ary Borenszweig 
wrote:

 One simple thing we did in Crystal is to allow invoking a 
 function with named arguments only for arguments that have a 
 default value. For example:

 void foo(int x, int y = 2, int z = 3) { ... }

 foo(x, y: 10);
 foo(x, y: 10, z: 20);
 foo(x, z: 30)

 But not this:

 foo(x: 10)

 The logic behind this is that named arguments are usually 
 wanted when you want to replace one of the default values while 
 keeping the others' defaults. You could specify names for 
 arguments that don't have a default value, but that only gives 
 a small readability aid. Changing a default value in the middle 
 is a new feature.

 This greatly simplifies the logic, since parameter reordering 
 can only happen for names that have default values and you can 
 always fill the gaps. Also, default values can also appear last 
 in a function signature.


Another thought I had is that an alternative could be to have 
some special syntax to say "use the default for this parameter."
I do not have experience implementing languages so perhaps I am 
wrong, but it seems like it should be possible for the compiler 
to get the default value and replace some placeholder with it.

Something like:
void foo(int a = 42, int b = 0){}
foo( default, 7); //rewritten to foo(42, 7);
Oct 14 2014
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Tuesday, 14 October 2014 at 21:21:23 UTC, 岩倉 澪 wrote:

 Something like:
 void foo(int a = 42, int b = 0){}
 foo( default, 7); //rewritten to foo(42, 7);


It is useful to have "_" mean "I don't care" when you have 
tuples. So you would then write:

"foo( _ , 7 )" and " _,y = get_point()"
Oct 15 2014
parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Wed, 15 Oct 2014 11:21:43 +0000
via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 On Tuesday, 14 October 2014 at 21:21:23 UTC, =E5=B2=A9=E5=80=89 =E6=BE=AA=


 wrote:

 Something like:
 void foo(int a =3D 42, int b =3D 0){}
 foo( default, 7); //rewritten to foo(42, 7);


=20
 It is useful to have "_" mean "I don't care" when you have=20
 tuples. So you would then write:
=20
 "foo( _ , 7 )" and " _,y =3D get_point()"


it better be "__" (two underscores). the rationale is simple: "__" is
clearly reserved for internal use, so it can has any meaning we need
without breaking any code. 'cause single underscore now can be used as
placeholder in `foreach (_; 0..42)`, *AND* still can be accessed as
normal var. besides, nested foreach with '_' is not working. but "__"
can generate unique temporary variable each time.
Oct 15 2014
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
ketmar:


 besides, nested foreach with '_' is not working. but "__"
 can generate unique temporary variable each time.


The point is to introduce a little breaking change in D and use 
"_" as "don't care", so you can reuse it for nested scoped and 
for tuple unpacking, and for other similar future purposes.

Bye,
bearophile
Oct 15 2014
parent =?UTF-8?B?IuWyqeWAiSDmvqoi?= <mio.iwakura gmail.com> writes:
On Wednesday, 15 October 2014 at 11:52:13 UTC, bearophile wrote:

 ketmar:


 besides, nested foreach with '_' is not working. but "__"
 can generate unique temporary variable each time.


 The point is to introduce a little breaking change in D and use 
 "_" as "don't care", so you can reuse it for nested scoped and 
 for tuple unpacking, and for other similar future purposes.

 Bye,
 bearophile


I agree that _ would be the ideal syntax, but why make a breaking 
change when it is unnecessary? __ would serve just as well and it 
is only one extra character. It is already reserved so it would 
be reasonable to put it to good use.
Oct 15 2014
prev sibling parent Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 13/10/14 09:47, Walter Bright via Digitalmars-d wrote:

 On 10/13/2014 1:29 AM, "岩倉 澪" wrote:

 Are there good reasons not to add something like this to the
 language, or is it simply a matter of doing the work? Has it been
 discussed much?


 
 Named parameters interact badly with overloading.


Groovy handles this OK.

(Python handles this fine by not having even a whiff of the
possibility of overloading ;-)

- -- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip:
sip:russel.winder ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iEYEARECAAYFAlQ78kYACgkQ+ooS3F10Be/mswCg20q2hDsmPBYkJpwr1c03fjVj
KVkAn1pmkQGjN2OATRbuDHHWu2xN9SyE
=hPA7
-----END PGP SIGNATURE-----
Oct 13 2014
prev sibling next sibling parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Mon, 13 Oct 2014 08:29:40 +0000
"=E5=B2=A9=E5=80=89 =E6=BE=AA" via Digitalmars-d <digitalmars-d puremagic.c=
om> wrote:


 I think optional named parameters would be a nice addition,=20
 either to the core language, or something like the monadic=20
 solution from that old thread in phobos.


if we'll add proper AA literals, they can be used instead. methinks.
Oct 13 2014
parent =?UTF-8?B?IuWyqeWAiSDmvqoi?= <mio.iwakura gmail.com> writes:
On Monday, 13 October 2014 at 10:53:50 UTC, ketmar via 
Digitalmars-d wrote:

 if we'll add proper AA literals, they can be used instead. 
 methinks.


I think this would be a decent alternative.

On Monday, 13 October 2014 at 16:08:08 UTC, ponce wrote:

 Work-around I see a lot in C++:

 ---------------

 bool filled = true;
 drawCircle(filled);

 ---------------

 instead of:

 ---------------

 drawCircle(true);

 ---------------


This doesn't provide all the benefit of named parameters (in 
particular, their use in combination with default arguments

Other workarounds include associative arrays, and the so-called 
"Named Parameter Idiom" 
http://www.parashift.com/c++-faq-lite/named-parameter-idiom.html
Oct 13 2014
prev sibling next sibling parent reply "ponce" <contact gam3sfrommars.fr> writes:
On Monday, 13 October 2014 at 08:29:42 UTC, 岩倉 澪 wrote:

 From what I've found, there was some work on this in the past 
 (http://forum.dlang.org/thread/wokfqqbexazcguffwiif forum.dlang.org?page=6#post-thclpgdlfxxhhfklwsoj
40forum.dlang.org), 
 but a pull request was never made/I don't seem to find 
 discussion about adding it as a feature anywhere.

 I think optional named parameters would be a nice addition, 
 either to the core language, or something like the monadic 
 solution from that old thread in phobos.

 Are there good reasons not to add something like this to the 
 language, or is it simply a matter of doing the work? Has it 
 been discussed much?


Work-around I see a lot in C++:

---------------

bool filled = true;
drawCircle(filled);

---------------

instead of:

---------------

drawCircle(true);

---------------
Oct 13 2014
parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Mon, 13 Oct 2014 16:08:07 +0000
ponce via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 Work-around I see a lot in C++:
=20
 ---------------
=20
 bool filled =3D true;
 drawCircle(filled);
=20
 ---------------
=20
 instead of:
=20
 ---------------
=20
 drawCircle(true);
=20
 ---------------


it's not the same, i thing. for this we have Flag in std.typecons, for
example.
Oct 13 2014
prev sibling next sibling parent reply "bachmeier" <no spam.com> writes:
On Monday, 13 October 2014 at 08:29:42 UTC, 岩倉 澪 wrote:

 From what I've found, there was some work on this in the past 
 (http://forum.dlang.org/thread/wokfqqbexazcguffwiif forum.dlang.org?page=6#post-thclpgdlfxxhhfklwsoj
40forum.dlang.org), 
 but a pull request was never made/I don't seem to find 
 discussion about adding it as a feature anywhere.

 I think optional named parameters would be a nice addition, 
 either to the core language, or something like the monadic 
 solution from that old thread in phobos.

 Are there good reasons not to add something like this to the 
 language, or is it simply a matter of doing the work? Has it 
 been discussed much?


My limited Scala experience from several years ago suggests this 
is not something worth doing. The names of parameters are part of 
the API. Suppose you have a method like

def foo(x: int = 1000, y: double = 0.0): double {}

If you later change the names to something more informative

def foo(reps: int = 1000, variance: double = 0.0): double {}

you've potentially broken existing code. Maybe there are better 
approaches than that of Scala, but doing anything like that to D 
would be a huge mistake for little gain. (I write a lot of R 
code, for which named parameters are the norm, so I understand 
the convenience.)
Oct 13 2014
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
bachmeier:


 def foo(x: int = 1000, y: double = 0.0): double {}

 If you later change the names to something more informative

 def foo(reps: int = 1000, variance: double = 0.0): double {}


You can use:

double foo(int deprecated(x) reps=100, deprecated(y) 
variance=0.0) {...}

Bye,
bearophile
Oct 13 2014
parent Walter Bright <newshound2 digitalmars.com> writes:
On 10/13/2014 4:09 PM, bearophile wrote:

 bachmeier:


 def foo(x: int = 1000, y: double = 0.0): double {}

 If you later change the names to something more informative

 def foo(reps: int = 1000, variance: double = 0.0): double {}


 You can use:

 double foo(int deprecated(x) reps=100, deprecated(y) variance=0.0) {...}


Please, no.
Oct 13 2014
prev sibling next sibling parent "Rei Roldan" <raroldan gmail.com> writes:
On Monday, 13 October 2014 at 08:29:42 UTC, 岩倉 澪 wrote:

 From what I've found, there was some work on this in the past 
 (http://forum.dlang.org/thread/wokfqqbexazcguffwiif forum.dlang.org?page=6#post-thclpgdlfxxhhfklwsoj
40forum.dlang.org), 
 but a pull request was never made/I don't seem to find 
 discussion about adding it as a feature anywhere.

 I think optional named parameters would be a nice addition, 
 either to the core language, or something like the monadic 
 solution from that old thread in phobos.

 Are there good reasons not to add something like this to the 
 language, or is it simply a matter of doing the work? Has it 
 been discussed much?


That's just taking laziness one step further :)
Oct 15 2014
prev sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
They are discussing about named arguments for C++:

http://www.reddit.com/r/cpp/comments/2jiai2/n4172_named_arguments/
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4172.htm

Bye,
bearophile
Oct 17 2014
parent =?UTF-8?B?IuWyqeWAiSDmvqoi?= <mio.iwakura gmail.com> writes:
Slightly off-topic, but I'm learning the constructed (human) 
language lojban, and the FA and zo'e constructs remind me of 
named parameters and _.
In lojban there are constructs called selbri that are kind of 
like a programming languages functions: vecnu = x1 sells x2 to x3 
for price x4
x1, x2, x3, x4 representing positional parameters
If you don't want to specify one you pass zo'e which is like the 
word "something."
If you leave off some sumti (args), it is equivilant to passing 
zo'e. Five selbri parameters have names, fa, fe, fi, fo, fu. So 
you can pass them in any order if you put those tags in front.

More on-topic: I don't really think named parameters are a 
worthwhile feature, but I really hope D gets __. That seems like 
it wouldn't have any major conflicts with implementing, and would 
give functions a bit of a boost in terms of expressiveness.
Oct 20 2014