On Friday, 23 August 2019 at 18:35:26 UTC, bachmeier wrote:
> On Friday, 23 August 2019 at 17:42:14 UTC, H. S. Teoh wrote:
>
>> But this:
>>
>> 	foo(x: 4, y: 8, z: 9,
>> 		screen: scr1, widget: wg2,
>> 		options: opts, menu: menu3);
>>
>> is no worse than this:
>>
>> 	FooParams params;
>> 	params.x = 4;
>> 	params.y = 8;
>> 	params.z = 9;
>> 	params.screen = scr1;
>> 	params.widget = wg2;
>> 	params.options = opts;
>> 	params.menu = menu3;
>> 	foo(params);
>
> What that leads to is this:
>
> foo(x: 4, y: 8, z: 9,
> 	screen: scr1, widget: wg2,
> 	options: opts, menu: menu3);
> foo(x: 4, y: 8, z: 9,
> 	screen: scr2, widget: wg2,
> 	options: opts, menu: menu3);
> foo(x: 4, y: 8, z: 9,
> 	screen: scr1, widget: wg1,
> 	options: opts, menu: menu3);
>
> You've got a combination of extreme verbosity, hard-to-read code, and a prolific bug generation machine.

How is that hard to read? Personally I think the FooParams version is more verbose and harder to read. Also the FooParams version forces default values on all parameters so when you forgot to specify one of the parameters, you won't get an error, which I consider to be very bad.

Also, you don't have to write the names if you don't want to.

> The answer to that is to start currying function arguments or write a customized function that calls foo while holding fixed certain parameters. It's extremely clear when you change a single parameter in a struct. And nobody had to learn yet another piece of syntax in order to read D code. The best anyone can say is that this is not harmful in simple cases.

This syntax is so simple that I think it's definitely worthwhile

On 24/08/2019 11:35 AM, Yuxuan Shui wrote:
> So, again, there are a lot of suggestions that we need reordering, default arguments skipping, etc. And I completely agree. If someone come forward and write a well thought out named argument DIP with those features, I would happily drop mine.
> 
> However, during the 6 months long review of this (and DIP 1020, but that one is in hiatus right now), no one did. People cares a lot about these features, but not enough to write a DIP.

DIP1020 is not on hiatus.
The editing is almost done.

On Fri, Aug 23, 2019 at 11:41:21PM +0000, Yuxuan Shui via Digitalmars-d wrote:
> On Friday, 23 August 2019 at 16:47:14 UTC, H. S. Teoh wrote:
[...]
> > Exactly the same objections I have against this DIP.  OT1H it's trying to get named arguments into the language, but OTOH it takes out what I would consider to be two of the most important reasons to *have* named arguments: skipping default parameters, and out-of-order argument passing.  Therefore, it essentially nullifies its own raison d'etre.
> 
> It DOES NOT prevent them from being added later. Like I have already reiterated multiple times, this is not the be-all and end-all named arguments DIP.

And that's exactly the problem: this DIP wants to introduce named arguments, but proposes a subset of functionality so weak that doesn't even offer what I consider to be two *major* advantages of having named arguments.  Which begs the question, why even bother?  Why not just take us all the way there and do a full DIP of the "be-all and end-all" of named arguments?


[...]
> > Furthermore, if this DIP hadn't shot itself in its own foot by not allowing out-of-order argument passing and skipping default parameters, then it would have actually made overly-long parameter lists actually *acceptable*, in the sense that the function could just supply default values for most of the parameters, and the caller can just name and pass the few arguments that it wants to be different from the defaults, and the rest don't have to be explicitly specified.
> 
> It does not always make sense to supply default values for parameters.
> 
> e.g createWindow(int width, int height)
> 
> What default value do you give them?
[...]

Then don't give them any defaults.  What makes you think you have to?


T

-- 
Without geometry, life would be pointless. -- VS

On Friday, August 23, 2019 10:47:14 AM MDT H. S. Teoh via Digitalmars-d wrote:
> On Fri, Aug 23, 2019 at 04:19:51PM +0000, Dennis via Digitalmars-d wrote:
> > On Friday, 23 August 2019 at 15:01:20 UTC, Andrei Alexandrescu wrote:
> > > Large parameter lists of which most have reasonable defaults is a marquee use case of named arguments. A proposal that works itself out of that opportunity cannot and should not be acceptable.
>
> Exactly the same objections I have against this DIP.  OT1H it's trying to get named arguments into the language, but OTOH it takes out what I would consider to be two of the most important reasons to *have* named arguments: skipping default parameters, and out-of-order argument passing.  Therefore, it essentially nullifies its own raison d'etre.
>
> > I'm personally not a fan of those argument lists the size of the Magna Cartas like you see in Python libraries: https://matplotlib.org/3.1.1/api/_as_gen/matplotlib.lines.Line2D.html#ma tplotlib.lines.Line2D I don't see it as a loss that this DIP doesn't enable those in D. If your function takes more than 6 arguments you should really consider creating a struct with configuration data.
>
> [...]
>
> But this DIP neither enables nor disables inordinately long parameter lists: the language already allows them!  The only thing worse than an overly-long parameter list is one in which you cannot (easily) tell which argument corresponds with which parameter, and that's something this DIP would fix (by letting you name the arguments so that they are self-documenting).  So your argument doesn't really detract from this DIP.
>
> Furthermore, if this DIP hadn't shot itself in its own foot by not allowing out-of-order argument passing and skipping default parameters, then it would have actually made overly-long parameter lists actually *acceptable*, in the sense that the function could just supply default values for most of the parameters, and the caller can just name and pass the few arguments that it wants to be different from the defaults, and the rest don't have to be explicitly specified.

Personally, I'm against named arguments in general. They make the parameter names part of the API, which adds another set of names that you have to get right up front and which will be bike-shedded to death. The _only_ use case IMHO where they add any real value is when you have a long parameter list where most of the parameters having default arguments. Such functions are usually a bad design, so I'm fine with not having named arguments in the language to make such designs seem more reasonable. If your parameter list is long enough that it doesn't work to go by the order of the arguments, then you already have a problem. But if we're going to add named arguments, then IMHO, the rare case where it actually makes sense to have a lot of parameters with default arguments is what named arguments are there to solve. So, if the DIP can't solve that, then IMHO, it's just making the language worse to no benefit.

- Jonathan M Davis

On Fri, Aug 23, 2019 at 07:09:48PM -0600, Jonathan M Davis via Digitalmars-d wrote:
> [...] But if we're going to add named arguments, then IMHO, the rare case where it actually makes sense to have a lot of parameters with default arguments is what named arguments are there to solve. So, if the DIP can't solve that, then IMHO, it's just making the language worse to no benefit.
[...]

Yeah, that's why I said, this DIP kinda nullifies its own raison d'etre. I withhold judgment on the value of named arguments in general, but at the very least, this DIP could have offered its primary benefits, which to me are (1) reordered arguments, and (2) skipping default arguments.

Without these two primary benefits, it's hard for me to imagine how this DIP could pull its own weight.  It's like promising to cook chicken pot pie, but when the dish arrives there's only pie and no chicken.  Who would pay for that?


T

-- 
IBM = I'll Buy Microsoft!

On Saturday, 24 August 2019 at 01:26:48 UTC, H. S. Teoh wrote:
> Without these two primary benefits, it's hard for me to imagine how this DIP could pull its own weight.  It's like promising to cook chicken pot pie, but when the dish arrives there's only pie and no chicken.  Who would pay for that?


I agree.

Without reordered and skipping default,  I consider in-place-inited struct is more useful then this DIP.

>> Furthermore, if this DIP hadn't shot itself in its own foot by not allowing out-of-order argument passing and skipping default parameters, then it would have actually made overly-long parameter lists actually *acceptable*, in the sense that the function could just supply default values for most of the parameters, and the caller can just name and pass the few arguments that it wants to be different from the defaults, and the rest don't have to be explicitly specified.
>
> It does not always make sense to supply default values for parameters.
>
> e.g createWindow(int width, int height)
>
> What default value do you give them?


See this quite often. Usually values of -1 are used to auto calculate based on the contents of the window.

There are a lot of instances default values are used. Named parameters are one of the few tools to use to keep those default values if you only want to modify one of them and there's multiple default value parameters.

On Saturday, 24 August 2019 at 01:43:31 UTC, Newbie2019 wrote:
> On Saturday, 24 August 2019 at 01:26:48 UTC, H. S. Teoh wrote:
>> Without these two primary benefits, it's hard for me to imagine how this DIP could pull its own weight.  It's like promising to cook chicken pot pie, but when the dish arrives there's only pie and no chicken.  Who would pay for that?
>
>
> I agree.
>
> Without reordered and skipping default,  I consider in-place-inited struct is more useful then this DIP.

struct is only one entity, so compiler knows what exactly initialized
but function can be overloaded
so which one should be called in sample below?

import std.stdio;
void foo(int a, int b) {writeln("0");}
void foo(int b, double a) {writeln("1");}
void main()
{
    foo(b: 10, 0);
}

On Friday, August 23, 2019 11:00:06 PM MDT a11e99z via Digitalmars-d wrote:
> On Saturday, 24 August 2019 at 01:43:31 UTC, Newbie2019 wrote:
> > On Saturday, 24 August 2019 at 01:26:48 UTC, H. S. Teoh wrote:
> >> Without these two primary benefits, it's hard for me to imagine how this DIP could pull its own weight.  It's like promising to cook chicken pot pie, but when the dish arrives there's only pie and no chicken.  Who would pay for that?
> >
> > I agree.
> >
> > Without reordered and skipping default,  I consider in-place-inited struct is more useful then this DIP.
>
> struct is only one entity, so compiler knows what exactly
> initialized
> but function can be overloaded
> so which one should be called in sample below?
>
> import std.stdio;
> void foo(int a, int b) {writeln("0");}
> void foo(int b, double a) {writeln("1");}
> void main()
> {
>      foo(b: 10, 0);
> }

The simple answer is to just make it illegal to mix named arguments with normal arguments. If you use a name with one of them, you have to use a name with all of them.

- Jonathna M Davis

On 8/23/2019 10:00 PM, a11e99z wrote:
> so which one should be called in sample below?
> 
> import std.stdio;
> void foo(int a, int b) {writeln("0");}
> void foo(int b, double a) {writeln("1");}
> void main()
> {
>      foo(b: 10, 0);
> }

According to my suggestion, "1" is unambiguously selected.

https://digitalmars.com/d/archives/digitalmars/D/DIP_1019--Named_Arguments_Lite--Community_Review_Round_2_327714.html#N327755