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

[Yuxuan Shui]

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.

> It would be like if we suddenly disabled the "private" modifier 
> and allowed everything to access private fields within structs 
> and classes.

I don't think this is a fair comparison.