DIP 1030--Named Arguments--Community Review Round 1 Discussion

[Jonathan Marler]

On Wednesday, 12 February 2020 at 21:47:12 UTC, Sasha wrote:
> On Wednesday, 12 February 2020 at 21:11:12 UTC, Jonathan Marler 
> wrote:
>> You could use variables to make it look nicer at the 
>> call-side, but the downside is there's no guarantee that those 
>> variable names have any relation to the names of the 
>> parameters. For example, this would still compile:
>>
>> makeWindow(x, width, y, height);
>>
>> This problem can't happen with named arguments.  Named 
>> arguments also saves you if the function arguments change 
>> names/meaning, i.e.
>>
>> ORIGINAL: void makeWindow(int x, int y, int width, int height)
>> MODIFIED: void makeWindow(int left, int top, int right, int 
>> bottom);
>>
>> The version that doesn't use named arguments will still 
>> compile and run:
>>
>> makeWindow(x, y, width, height);
>>
>> But named arguments would catch the problem at compile-time:
>>
>> makeWindow(x: 67, y: 98, width: 100, height: 100); // error no 
>> argument named 'x', 'y', 'width', 'height'
>
> OK, now let's see a problem with named arguments, imagine this:
>
> makeWindow(x, y, width, height);
>
> You can call this function like:
>
> makeWindow(x: 67, y: 98, width: 100, height: 100); // Name 
> Arguments
> makeWindow(67, 98, 100, 100); // Constants
> makeWindow(x, y, width, height); // Variables
>
> So far so good, but later someone decides to rename some 
> parameters to:
>
> makeWindow(posx, posy, width, height); // Note: x => posx and y 
> => posy
>
> makeWindow(x: 67, y: 98, width: 100, height: 100); // Ops not 
> working anymore!
> makeWindow(67, 98, 100, 100); // Constants still works
> makeWindow(x, y, width, height); // Variables Still works
>
> What I mean is that we need to balance this better, you showed 
> a defect without Named Arguments and I'm showing a problem with.
>
> But one thing that called my attention is that for what I see 
> C++ doesn't has this feature, and proposes were rejected 
> because the problems that would be created with this feature.
>
> Sasha.

My point was the the error is caught at compile-time rather than 
runtime, which I think is a pro in the named arguments column.

That being said, the issue you brought up with named arguments is 
a valid issue and would be my biggest argument against them.  
They dramatically increase the surface area of the API which will 
lead to more breakage between libraries.  For this reason and the 
fact that I think named arguments are only useful in a minority 
of cases (maybe 25%?) I think it would be  better to make named 
arguments "opt-in" so that each library can choose when to make 
their parameter names apart of their API.