DIP 1019--Named Arguments Lite--Final Review

[Andrei Alexandrescu]

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.