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

[Jonathan Marler]

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.

By the way, I like what the DIP is trying to do, where it is 
trying to enable named parameters using the "least common 
denominator".   It attempts to do as little as possible to 
increase the likelihood of acceptance and leaves room for future 
improvements to address things like re-ordering/omission of 
default parameters, features which may or may not be justified 
but shouldn't keep us from having named parameters.

However, the way in which it was designed where it suddenly 
exposes the parameter names of all functions to all callers is 
not what we want.  I think the "least common denominator" is to 
provide some way for the function definition to distinguish 
between named and un-named parameters. Something like this:

void foo(int a, int b, int c, alias int d, int e, int f)
              ^                         ^
   unnamed parameters (left of alias)   named parameters (right of 
alias)

foo(1, 2, 3, d:4, e:5, f:6)