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

[Jonathan Marler]

On Tuesday, 11 February 2020 at 07:04:34 UTC, Walter Bright wrote:
> On 2/10/2020 3:20 PM, Jonathan Marler wrote:
>>   I took a quick look at std.math in phobos to see what some 
>> of the current argument names are:
>> 
>> auto conj(Num)(Num z) @safe pure nothrow @nogc
>> auto abs(Num)(Num x) @nogc pure nothrow
>> real cos(real x) @safe pure nothrow @nogc { pragma(inline, 
>> true); return core.math.cos(x); }
>> auto sin(creal z) @safe pure nothrow @nogc
>> auto sin(ireal y) @safe pure nothrow @nogc
>> 
>> So we have some of this:
>> 
>> conj(z:someValue);
>> abs(x:someValue);
>> sin(y:someValue);
>> 
>> Now that parameter names are apart of the function's API, this 
>> inconsistency starts to matter
>
> It isn't inconsistent. In math, z=x+iy is normal notation, i.e. 
> x for real numbers, y for imaginary, and z for complex.

conj and abs are using template parameters.  So if you're passing 
an imaginary number to conj you use "z", abs you use "x", and sin 
you use "y".

ireal i;
conj(z: i);
abs(x: i);
sin(y: i);

>
> Besides, I doubt there's much of any point for using named 
> parameters for those functions.

True.  I estimate around 75% of functions in general don't 
benefit from named parameters.  So the question becomes, what do 
we do about parameter name inconsistency in these cases for the 
standard libraries?  If we don't think named parameters are 
useful for a function, will we leave them be?   If so, can we 
come up with a criteria we can use to determine when named 
parameters make sense?  I think this would help greatly in this 
transition to named parameters to help avoid alot of the 
bikeshedding I see coming when this is enabled.

I was also hoping to get some answers from the leadership to the 
other questions:

>> Will druntime/phobos try to come up with standard names for 
>> these situations?

For example, for math functions like the ones I mentioned, are we 
going to normalize on "x", "y" and "z" depending on the type?  
And if it's a template that could accept any type, what name 
would we use in that case?  Of course, if the answer to the 
previous question is that we won't bother with functions that 
don't make sense with named parameters, then this is a bad 
example.  But the question still stands for functions that do 
make sense, do you think we should come up with a standard set of 
names to promote consistency accross the standard libraries, and 
3rd party libraries?

Also these questions:
>> Will we try to fix these names before integrating support for 
>> named parameters?
>> If we need to change names later, what will the policy be for 
>> druntime/phobos for making parameter name changes when 
>> inconsistencies are discovered?

Also came up with another question looking through some of the 
external function declarations in druntime like the ones in 
https://github.com/dlang/druntime/blob/master/src/core/sys/windows/winbase.d

It looks like the parameter names have been stripped out for the 
windows functions.  Do you think we should add parameter names in 
those functions?  If we do want to add names, do you think we 
should we use the hungarian notation parameter names from 
windows, or no?