DIP 1020--Named Parameters--Community Review Round 2

[rikki cattermole]

On 11/09/2019 3:37 AM, Paul Backus wrote:
> I think you've misunderstood what 12345swordy and I are saying. The 
> concern is not that DIP 1020 (or any other implementation of named 
> arguments) will cause breakage *itself*, but that making parameter names 
> part of a function's public interface could lead indirectly to *future* 
> code breakage if any of those names are changed.
> 
> 12345swordy's point #3 was that the above concern is, in his opinion, 
> overblown, and that therefore we shouldn't bother requiring a @named 
> attribute on parameters to address it. Personally, I share this opinion; 
> my own experience in Python (which handles named arguments similarly to 
> C#) is that parameter-name changes are not a problem in practice.

Oh okay in that case, I do agree with both of you that potential 
breakage for name changes is over blown.

However DIP 1020 is opt-in and that design decision permeates throughout 
the entire DIP. Unlike syntax, I cannot change this without recreating 
the DIP from scratch.

To me named arguments work best when the API author is the one who made 
the decision to make it named. Not the API user. Ada and Python are both 
good examples of opt-in named arguments made by the API author.

Ultimately D is a production language.
Adding a language feature like named arguments so late could end badly 
if it intends to add new patterns of code that do not have solid 
examples in many existing code bases.