Re: Why is there no named parameter support?
On Tue, 09 Jun 2015 09:50:15 +, Marc Schütz 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.
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
ability to forward calls as is in templates. but i believe that this
can be dealt with later -- i.e. in another PR.
signature.asc
Description: PGP signature
Re: Why is there no named parameter support?
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.
Re: Why is there no named parameter support?
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. signature.asc Description: PGP signature
Re: Why is there no named parameter support?
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. signature.asc Description: PGP signature
Why is there no named parameter support?
Is there any reasons/difficulties for not implementing named parameters? There is clearly a need: http://forum.dlang.org/thread/wokfqqbexazcguffw...@forum.dlang.org#post-pxndhoskpjxvnoacajaz:40forum.dlang.org
Re: Why is there no named parameter support?
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/wokfqqbexazcguffw...@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
Re: Why is there no named parameter support?
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/wokfqqbexazcguffw...@forum.dlang.org#post-pxndhoskpjxvnoacajaz:40forum.dlang.org http://forum.dlang.org/thread/hdxnptcikgojdkmld...@forum.dlang.org
Re: Why is there no named parameter support?
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
Re: Why is there no named parameter support?
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.
Re: Why is there no named parameter support?
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/wokfqqbexazcguffw...@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
Re: Why is there no named parameter support?
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
