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

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

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

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
>
>

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

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.

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

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 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 `createWindow(10, 10, 20, 40)`. sure, one can do all kind of acrobatics to emulate that, but why? ah, another thing that Walter never used so he doesn't see it as a good thing to have.

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 arguments peacefully.

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.