On Friday, 23 August 2019 at 15:01:20 UTC, Andrei Alexandrescu wrote:
> Sadly I oppose it on the following grounds:
>
> "Named arguments proposed by this DIP have no effect on the ordering of arguments in function calls."
>
> "Named arguments proposed by this DIP do not allow default parameters to be skipped."
>
> These two limitations are as useful and help each other as much as a nausea and a cough.

As Andrei said these are the two features I would look for in named arguments and this doesn't have either. It would be better to go back to the drawing board.

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.

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#matplotlib.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.

On Friday, 23 August 2019 at 15:01:20 UTC, Andrei Alexandrescu wrote:
> I was unconvinced by the argument that these can be added later. Language design is peculiar in that incrementalism doesn't work well - it must come all at once. There are exceptions and arguments that can be made but there's overwhelming evidence that incremental language design is just not a good way to go about things.

In many cases (like the recent scope/@safe related proposals) I agree that implementing only part of a design has little value, but in this case the proposal has merits even in this limited form. Take for example this line:

glfwCreateWindow(1280, 720, "my window", null, null);

You can easily guess what the first three arguments are, but what about those two nulls? It could be made clearer like this:

glfwCreateWindow(1280, 720, "my window", fullScreenMonitor: null, parentWindow: null);

You can't leave `fullScreenMonitor` to the default while passing `parentWindow` with this DIP, but writing out that argument doesn't seem like a big loss to me. And even if it is, limitations can easily be lifted without much friction. If it turns out that reordering causes problems down the line, deprecating them would be more of a hassle.

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#matplotlib.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.


T

-- 
If you're not part of the solution, you're part of the precipitate.

On Friday, 23 August 2019 at 16:47:14 UTC, H. S. Teoh wrote:
>> 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#matplotlib.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.

Hopefully we don't make changes to the language in order to reduce the cost of bad programming practice. There's a real cost to encouraging long parameter lists, because while the "usual" case isn't so bad:

foo(x: 4, y: 8)

the case where you specify nine parameters is quite ugly, spilling onto multiple lines and making it hard to read. IMO, it's okay to make language design decisions assuming existing data structures (structs in this case) will be used when they're appropriate.

On Friday, 23 August 2019 at 16:47:14 UTC, H. S. Teoh wrote:
> 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.
+1
The things that I most expect from named arguments.

On Fri, Aug 23, 2019 at 05:16:16PM +0000, bachmeier via Digitalmars-d wrote:
> On Friday, 23 August 2019 at 16:47:14 UTC, H. S. Teoh wrote:
[...]
> > 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.
> 
> Hopefully we don't make changes to the language in order to reduce the cost of bad programming practice. There's a real cost to encouraging long parameter lists, because while the "usual" case isn't so bad:
> 
> foo(x: 4, y: 8)
> 
> the case where you specify nine parameters is quite ugly, spilling onto multiple lines and making it hard to read.
[...]

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


T

-- 
Just because you survived after you did it, doesn't mean it wasn't stupid!

On 8/23/19 12:19 PM, Dennis 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.
> 
> 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#matplotlib.lines.Line2D 

Abuse is a possibility.

> In many cases (like the recent scope/@safe related proposals) I agree that implementing only part of a design has little value, but in this case the proposal has merits even in this limited form. Take for example this line:
> 
> glfwCreateWindow(1280, 720, "my window", null, null);
> 
> You can easily guess what the first three arguments are, but what about those two nulls? It could be made clearer like this:
> 
> glfwCreateWindow(1280, 720, "my window", fullScreenMonitor: null, parentWindow: null);
> 
> You can't leave `fullScreenMonitor` to the default while passing `parentWindow` with this DIP, but writing out that argument doesn't seem like a big loss to me. And even if it is, limitations can easily be lifted without much friction. If it turns out that reordering causes problems down the line, deprecating them would be more of a hassle.

Funny you should mention this, because the obvious problem is this doesn't work:

glfwCreateWindow(1280, 720, "my window", parentWindow: null, fullScreenMonitor: null);

On 8/23/19 1:42 PM, H. S. Teoh wrote:
> On Fri, Aug 23, 2019 at 05:16:16PM +0000, bachmeier via Digitalmars-d wrote:
>> On Friday, 23 August 2019 at 16:47:14 UTC, H. S. Teoh wrote:
> [...]
>>> 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.
>>
>> Hopefully we don't make changes to the language in order to reduce the
>> cost of bad programming practice. There's a real cost to encouraging
>> long parameter lists, because while the "usual" case isn't so bad:
>>
>> foo(x: 4, y: 8)
>>
>> the case where you specify nine parameters is quite ugly, spilling
>> onto multiple lines and making it hard to read.
> [...]
> 
> 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);

Exactly. It seems that for short lists (2-3 arguments) naming would be a net negative (add notational overhead when there's little possibility of a confusion to start with). Then, when the list gets longer it actually makes matters _worse_ because it disallows skipping of defaulted arguments.

This can't go.

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

On Fri, Aug 23, 2019 at 01:59:38PM -0400, Andrei Alexandrescu via Digitalmars-d wrote:
> On 8/23/19 1:42 PM, 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);
> 
> Exactly. It seems that for short lists (2-3 arguments) naming would be a net negative (add notational overhead when there's little possibility of a confusion to start with). Then, when the list gets longer it actually makes matters _worse_ because it disallows skipping of defaulted arguments.

Yes, in the case of a proxy argument struct, you can define defaults in the struct definition and just set the parameters you want, which is a better solution than this DIP.


> This can't go.

I think the way to move forward is to expand the scope of this DIP to allow reordering and skipping over default arguments.  I just don't see the benefit of going through all the trouble of the DIP process and subsequent implementation work, only to end up with a half-hearted feature that doesn't even offer these two most desirable things of a named argument implementation.


T

-- 
Without outlines, life would be pointless.