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

[Jonathan Marler]

On Thursday, 6 February 2020 at 06:08:59 UTC, Mike Parker wrote:
> This is the feedback thread for the first round of Community 
> Review for DIP 1030, "Named Arguments":
>
> https://github.com/dlang/DIPs/blob/44b0d4ec0da6a2e797ede748fb1e81cd6db10371/DIPs/DIP1030.md
>
> Here in the discussion thread, you are free to discuss anything 
> and everything related to the DIP. Express your support or 
> opposition, debate alternatives, argue the merits... in other 
> words, business as usual.
>
> However, if you have any specific feedback for how to improve 
> the the proposal itself, then please post it in the feedback 
> thread. The feedback thread will be the source for the review 
> summary I write at the end of this review round. I will post a 
> link to that thread immediately following this post. Just be 
> sure to read and understand the Reviewer Guidelines before 
> posting there:
>
> https://github.com/dlang/DIPs/blob/master/docs/guidelines-reviewers.md
>
> The review period will end at 11:59 PM ET on February 20, or 
> when I make a post declaring it complete. Discussion in this 
> thread may continue beyond that point.
>
> At the end of Round 1, if further review is deemed necessary, 
> the DIP will be scheduled for another round of Community 
> Review. Otherwise, it will be queued for the Final Review and 
> Formal Assessment.
>
> Please stay on topic here. I will delete posts that are 
> completely off topic.

I'm curious what the current state of druntime/phobos is with 
parameter name consistency.
  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 as changing it breaks the API.  
Will druntime/phobos try to come up with standard names for these 
situations?  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 consider the case when overloads use different parameter 
names.  std.math.sin uses 'z' for creal arguments and 'y' for 
ireal arguments.  This can cause issues during refactor as one 
needs to re-check all parameter names when changing types of 
arguments. i.e.

sin(z:someValue);

If you change the type of someValue from creal to ireal, then 
this would still call the creal overload, perhaps unexpectedly.