DIP 1019--Named Arguments Lite--Final Review

[bachmeier]

On Friday, 23 August 2019 at 23:46:43 UTC, Yuxuan Shui wrote:
> 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?

I suppose that's up to each programmer to define, but I don't see 
anything fun about having to look at eight named parameters to 
see which have changed from one call to the next. If you're doing 
a simulation with six different configurations, you don't want to 
have to specify all of the parameters every time, but the "easy 
approach" quickly becomes the default, and that's exactly what 
you'd be stuck with.

> Personally I think the FooParams version is more verbose and 
> harder to read.

Maybe an example will make my point more clear. You start with 
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);

Then you change a single parameter and call foo again:

params.x = 5;
foo(params);

It's crystal clear what is the difference in those two calls to 
foo. No need to parse a large list of arguments and hope you get 
right which parameters changed and which didn't. It also saves a 
lot of typing/copying and pasting. Large blocks of nearly 
duplicated code is a terrible thing that should be avoided at all 
costs. That's what you get when you have a large number of 
function arguments, and it's bad practice. There's always a cost 
to adding syntax (think about the person learning the language) 
so new syntax better pay big dividends.

> Also the FooParams version forces default values on all 
> parameters so when you forgot to specify one of the parameters

To be honest, I don't understand why a struct would force default 
parameters on you, but even if it did, that's a problem with 
default parameters, not structs. You'd have the same thing if you 
forgot to specify one of the parameters of a function call. 
Which, I'll note, is a whole lot easier to do when you're engaged 
in copy and paste because function calls are not reusable.