DIP 1019--Named Arguments Lite--Community Review Round 2

[Jonathan Marler]

On Friday, 7 June 2019 at 14:13:42 UTC, Yuxuan Shui wrote:
> On Thursday, 6 June 2019 at 19:17:38 UTC, Jonathan Marler wrote:
>> On Wednesday, 5 June 2019 at 13:03:26 UTC, Mike Parker wrote:
>>> [...]
>>
>> There's a big issue with this DIP.  It immediately allows any 
>> function call to increase coupling with the corresponding 
>> function definition with no way to disable it.  I agree that 
>> named parameters can increase readability, however, in the 
>> majority of cases they actually just add extra noise, i.e.
>>
>> [...]
>
> See also: 
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4172.htm
>
> The answer to objection #3 addresses your concern.

A good idea to get data like this. But I think what will happen 
if/when we enable named arguments is that there will be a spike 
in the number of changes to parameter names. The idea being that 
now that they are apart of the interface, we will want to 
normalize names for things like opCmp, opEquals, copy functions, 
one value operation functions, etc.

square(x: 10);
cube(num: 10);
quad(val: 10);

These would be examples of functions that don't benefit from 
named arguments, but because we've exposed the parameter names of 
every function, we've add a new burden to maintain/normalize 
these names for no benefit. At least, no benefit for these 
particular functions.

If we make it "opt-in", we only need to be concerned with 
functions that make their parameter names public, and when we 
make them public, we can normalize the parameter names at the 
same time knowing that we aren't breaking anything.