www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Why is there no named parameter support?

reply "Yuxuan Shui" <yshuiv7 gmail.com> writes:
Is there any reasons/difficulties for not implementing named 
parameters?

There is clearly a need:

http://forum.dlang.org/thread/wokfqqbexazcguffwiif forum.dlang.org#post-pxndhoskpjxvnoacajaz:40forum.dlang.org
Jun 08 2015
next sibling parent "Idan Arye" <GenericNPC gmail.com> writes:
On Monday, 8 June 2015 at 20:36:10 UTC, Yuxuan Shui wrote:

 Is there any reasons/difficulties for not implementing named 
 parameters?

 There is clearly a need:

 http://forum.dlang.org/thread/wokfqqbexazcguffwiif forum.dlang.org#post-pxndhoskpjxvnoacajaz:40forum.dlang.org


http://forum.dlang.org/thread/hdxnptcikgojdkmldzrk forum.dlang.org
Jun 08 2015
prev sibling next sibling parent Jonathan M Davis via Digitalmars-d-learn writes:
On Monday, June 08, 2015 20:36:05 Yuxuan Shui via Digitalmars-d-learn wrote:

 Is there any reasons/difficulties for not implementing named
 parameters?

 There is clearly a need:

 http://forum.dlang.org/thread/wokfqqbexazcguffwiif forum.dlang.org#post-pxndhoskpjxvnoacajaz:40forum.dlang.org


Function overloading and named arguments do not play well together, and we
have function overloading, so we're not going to have named arguments.
Walter made that clear at dconf. Now, as Idan pointed out in his reply, work
has been done implement them via a library solution for those that want to,
so you might get something there, but not in the language itself.

- Jonathan M Davis
Jun 08 2015
prev sibling next sibling parent Timothee Cour via Digitalmars-d-learn <digitalmars-d-learn puremagic.com> writes:
nim has both overloading and named arguments (with reordering and defaults
allowed): http://nim-lang.org/docs/tut1.html#procedures-named-arguments
and it doesn't seem to cause issues.

Is there a document / thread that explains the argument against named
arguments in more details than 'do not play well together' ?



On Mon, Jun 8, 2015 at 10:45 PM, Jonathan M Davis via Digitalmars-d-learn <
digitalmars-d-learn puremagic.com> wrote:


 On Monday, June 08, 2015 20:36:05 Yuxuan Shui via Digitalmars-d-learn
 wrote:

 Is there any reasons/difficulties for not implementing named
 parameters?

 There is clearly a need:


 http://forum.dlang.org/thread/wokfqqbexazcguffwiif forum.dlang.org#post-pxndhoskpjxvnoacajaz:40forum.dlang.org

 Function overloading and named arguments do not play well together, and we
 have function overloading, so we're not going to have named arguments.
 Walter made that clear at dconf. Now, as Idan pointed out in his reply,
 work
 has been done implement them via a library solution for those that want to,
 so you might get something there, but not in the language itself.

 - Jonathan M Davis
Jun 08 2015
prev sibling next sibling parent reply Jonathan M Davis via Digitalmars-d-learn writes:
On Monday, June 08, 2015 23:18:50 Timothee Cour via Digitalmars-d-learn wrote:

 nim has both overloading and named arguments (with reordering and defaults
 allowed): http://nim-lang.org/docs/tut1.html#procedures-named-arguments
 and it doesn't seem to cause issues.

 Is there a document / thread that explains the argument against named
 arguments in more details than 'do not play well together' ?


Probably not, but Walter was quite adamant when it was discussed at dconf
that it's a disaster to mix named arguments and function overloading in the
same language. Maybe it's not as bad as he thinks it is, but personally, I
think that named arguments are a terrible idea in general, so I'm not about
to try and support a position that tries to bring them into D.

- Jonathan M Davis
Jun 08 2015
parent ketmar <ketmar ketmar.no-ip.org> writes:
On Mon, 08 Jun 2015 20:32:56 -0700, Jonathan M Davis via
Digitalmars-d-learn wrote:


 is, but personally, I think that named arguments are a terrible idea in
 general, so I'm not about to try and support a position that tries to
 bring them into D.


it's a perfect thing. i always hate that "Flag" thingy, and with named=20
arguments i finally got rid of it.

  void foo (bool skipSomething);

  foo(skipSomething:true);

no more additional imports and additional types for the simple things.

besides, i like `createWindow(x:10, y:10, width:20, height:40)` more than=20
`createWindow(10, 10, 20, 40)`. sure, one can do all kind of acrobatics=20
to emulate that, but why? ah, another thing that Walter never used so he=20
doesn't see it as a good thing to have.=
Jun 09 2015
prev sibling next sibling parent reply Timothee Cour via Digitalmars-d-learn <digitalmars-d-learn puremagic.com> writes:
On Mon, Jun 8, 2015 at 11:32 PM, Jonathan M Davis via Digitalmars-d-learn <
digitalmars-d-learn puremagic.com> wrote:


 On Monday, June 08, 2015 23:18:50 Timothee Cour via Digitalmars-d-learn
 wrote:

 nim has both overloading and named arguments (with reordering and


 defaults

 allowed): http://nim-lang.org/docs/tut1.html#procedures-named-arguments
 and it doesn't seem to cause issues.

 Is there a document / thread that explains the argument against named
 arguments in more details than 'do not play well together' ?


 Probably not, but Walter was quite adamant when it was discussed at dconf
 that it's a disaster to mix named arguments and function overloading in the
 same language. Maybe it's not as bad as he thinks it is, but personally, I
 think that named arguments are a terrible idea in general, so I'm not about
 to try and support a position that tries to bring them into D.

 - Jonathan M Davis


I'd be very interested in reading more about those reasons beyond FUD.
The arguments in favor have been repeated many times over, and the only
argument against that I've heard ('overloading and named arguments do not
play well together') doesn't seem valid, given the precedent in nim.
Jun 08 2015
parent reply "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
On Tuesday, 9 June 2015 at 05:39:06 UTC, Timothee Cour wrote:

 I'd be very interested in reading more about those reasons 
 beyond FUD.
 The arguments in favor have been repeated many times over, and 
 the only
 argument against that I've heard ('overloading and named 
 arguments do not
 play well together') doesn't seem valid, given the precedent in 
 nim.


The only problems I can think of is if they affect name mangling, 
because then you would need to specify the names on each call. As 
long as they are optional syntax sugar, like in ketmar's POC 
implementation, they will probably work well.
Jun 09 2015
parent ketmar <ketmar ketmar.no-ip.org> writes:
On Tue, 09 Jun 2015 09:50:15 +0000, Marc Sch=C3=BCtz wrote:


 On Tuesday, 9 June 2015 at 05:39:06 UTC, Timothee Cour wrote:

 I'd be very interested in reading more about those reasons beyond FUD.
 The arguments in favor have been repeated many times over, and the only
 argument against that I've heard ('overloading and named arguments do
 not play well together') doesn't seem valid, given the precedent in
 nim.


=20
 The only problems I can think of is if they affect name mangling,
 because then you would need to specify the names on each call. As long
 as they are optional syntax sugar, like in ketmar's POC implementation,
 they will probably work well.


they have to affect mangling for templates, though, if we want the=20
ability to forward calls "as is" in templates. but i believe that this=20
can be dealt with later -- i.e. in another PR.=
Jun 09 2015
prev sibling parent reply Jonathan M Davis via Digitalmars-d-learn writes:
On Tuesday, June 09, 2015 01:38:56 Timothee Cour via Digitalmars-d-learn wrote:

 On Mon, Jun 8, 2015 at 11:32 PM, Jonathan M Davis via Digitalmars-d-learn <
 digitalmars-d-learn puremagic.com> wrote:


 On Monday, June 08, 2015 23:18:50 Timothee Cour via Digitalmars-d-learn
 wrote:

 nim has both overloading and named arguments (with reordering and


 defaults

 allowed): http://nim-lang.org/docs/tut1.html#procedures-named-arguments
 and it doesn't seem to cause issues.

 Is there a document / thread that explains the argument against named
 arguments in more details than 'do not play well together' ?


 Probably not, but Walter was quite adamant when it was discussed at dconf
 that it's a disaster to mix named arguments and function overloading in the
 same language. Maybe it's not as bad as he thinks it is, but personally, I
 think that named arguments are a terrible idea in general, so I'm not about
 to try and support a position that tries to bring them into D.

 - Jonathan M Davis


 I'd be very interested in reading more about those reasons beyond FUD.
 The arguments in favor have been repeated many times over, and the only
 argument against that I've heard ('overloading and named arguments do not
 play well together') doesn't seem valid, given the precedent in nim.


Then talk with Walter about it. Whether he's right or not is up for debate,
but it's certainly not FUD. He gave good examples, but I don't remember what
they were at this point.

Personally, I hate how named arguments affect the API (e.g. the names of the
parameters suddenly become part of the API), and for the most part, the only
times that they're worth much is when you have so many function parameters
that you should be creating structs to hold those values anyway. I don't
want them in the language, and I'm very glad that Walter is against them, so
I didn't feel the need to try and remember all he said about why they were a
bad idea.

- Jonathan M Davis
Jun 08 2015
parent ketmar <ketmar ketmar.no-ip.org> writes:
On Mon, 08 Jun 2015 22:58:10 -0700, Jonathan M Davis via
Digitalmars-d-learn wrote:


 Personally, I hate how named arguments affect the API (e.g. the names of
 the parameters suddenly become part of the API), and for the most part,
 the only times that they're worth much is when you have so many function
 parameters that you should be creating structs to hold those values
 anyway. I don't want them in the language, and I'm very glad that Walter
 is against them, so I didn't feel the need to try and remember all he
 said about why they were a bad idea.


the funny thing is that named arguments can coexist with unnamed=20
arguments peacefully.=
Jun 09 2015