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

[12345swordy]

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.

This has been brought up in the discussion regarding named 
arguments for DIP1020 (more specifically the @named attribute) 
and so far I am not convinced that this is an issue that needs to 
be address, and found it be be overblown given that we have 
powerful rename tools at this day of age.

Having it "opt-in" have it own downsides as the users have to 
request library developers to add the capability to their 
libraries. Among many other issues that were brought up and 
discuss with "opt-in"ing DIP1020.

Alex