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

[Gregor Mückl]

On Friday, 7 June 2019 at 15:15:40 UTC, Jonathan Marler wrote:
> On Friday, 7 June 2019 at 12:09:51 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:
>>>> This is the feedback thread for the second round of 
>>>> Community Review for DIP 1019, "Named Arguments Lite":
>>>>
>>>> https://github.com/dlang/DIPs/blob/9c9cc39246de4c449fe1e6cb6b27f7e426ff1eb9/DIPs/DIP1019.md
>>>>
>>>> All review-related feedback on and discussion of the DIP 
>>>> should occur in this thread. The review period will end at 
>>>> 11:59 PM ET on June 19, or when I make a post declaring it 
>>>> complete.
>>>>
>>>> At the end of Round 2, 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.
>>>>
>>>> I have recently made minor revisions to the DIP process and 
>>>> implemented guidelines for reviewers. Anyone intending to 
>>>> post feedback in this thread is expected to be familiar with 
>>>> the reviewer guidelines:
>>>>
>>>> https://github.com/dlang/DIPs/blob/master/docs/guidelines-reviewers.md
>>>>
>>>> I also recommend that everyone read my recent blog post on 
>>>> the topic:
>>>>
>>>> https://dlang.org/blog/2019/06/04/revisions-to-the-dip-process/
>>>>
>>>> To be clear, I will be moving (copying, deleting, and 
>>>> pasting in a new thread) posts that do not adhere to the 
>>>> reviewer guidelines. Please direct any comments on the new 
>>>> documentation to a new thread or to personal email. Please, 
>>>> let's keep the review discussion on topic.
>>>>
>>>> Thanks in advance to all who participate.
>>>
>>> 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.
>>>
>>> add(int x, int y) // parameter names not helpful
>>> square(float x)  // parameter names not helpful
>>> write(string s) // parameter names not helpful
>>> void opEquals(T)(ref T other) // parameter names not helpful
>>>
>>> Of course there are many cases where named arguments are very 
>>> helpful (the DIP provides some examples of this).
>>>
>>> However, if you suddenly allow every caller to specify the 
>>> argument names to any parameter on any function, you've added 
>>> a whole new set of dependencies between every function and 
>>> its callers.  A layer of protection/encapsulation has been 
>>> completely removed.  It would be like if we suddenly disabled 
>>> the "private" modifier and allowed everything to access 
>>> private fields within structs and classes.
>>>
>>> Languages like python that uses kwargs don't expose the names 
>>> of all parameters.  They are able to pick and choose which 
>>> parameters should be named.  This allows them to keep that 
>>> layer of protection/encapsulation for the parameters where 
>>> the name doesn't matter to the caller, just like when you 
>>> have private fields where the name doesn't matter to an 
>>> outside component.  D should follow this pattern as it has 
>>> been successful in other languages and the alternative has 
>>> too much disadvantage.  Allowing a parameter to be named at 
>>> the call-site should be an "opt-in" feature done at the 
>>> function definition, so as not to expose the names of all the 
>>> other parameters that don't make sense to expose to the 
>>> caller.
>>
>> Where were you during the last community review? :)
>>
>> Last time literally _everyone_ is arguing against named 
>> parameters being opt-in, and that's why I removed the 
>> opt-in-ness (the @named attribute) from the DIP.
>>
>
> I'm not actually sure if they should be opt-in. I'm pointing 
> out the problem with them always being on. They way I suggested 
> for them to be opt-in has 2 problems. One is that libraries 
> will need to break compatibility with older compilers to enable 
> them. Without opt-in, only the caller needs to do this. The 
> second is that it users will have to wait for libraries to 
> update before they can use the feature, and libraries may be 
> hesitant to update to remain compatible with older compilers, 
> at least for a while.
>
> I'm just pointing out a problem I see. We should all be aware 
> of the problem. Whether or not the problem is a big deal or had 
> a good solution is another question. I think it's a big deal, 
> and we should solve it if we can.
>

C# has had named arguments for quite a while now without any way 
to opt in or opt out. If you want to name a function argument, 
you just do it. If it breaks, it breaks. I haven't seen breakage 
from that in practice, yet. Mostly, because people only use that 
syntax for complex functions that have long parameter lists or 
challenging parameter lists with 4 to 5 boolean parameters in row 
or something borderline insane like that. So, I'd say that it's 
in the ballpark of one in 1000 LoCs or less that actually use 
that language feature.

Let's be real here: when is renaming a function argument the only 
change that happens to a function signature? If the argument's 
name and semantics change, the function's semantics change as 
well. This means that you need to review all your call sites 
anyway. And in my experience, even in large code bases, only a 
small section of the code is called from so many places that this 
is onerous. These are the same pieces of code that calcify into 
near-immutability anyway, because the slightest change is going 
to break something somewhere else, anyway.

I'll just suggest a simple canary here: C# is a popular language 
and a lot has been written about it. How easy is it to find a 
statement that complains about the usage of named function 
arguments?