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

[Jonathan Marler]

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.