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

[Yuxuan Shui]

On Sunday, 3 March 2019 at 10:50:05 UTC, Joseph Rushton Wakeling 
wrote:
> On Friday, 1 March 2019 at 00:49:25 UTC, Rubn wrote:
>> I don't agree with this at all. The feature becomes all but 
>> useless, it's either all in or just don't include it. So many 
>> things are already part of the API, and this will be an opt-in 
>> feature for the user (not the library developer). The user can 
>> choose to use the variable names if they want, knowing full 
>> well if the author pleases they can change it, but this will 
>> be no different than changing the variable name of struct.
>
> It's not comparable to changing the variable name of a struct, 
> because if that struct is a public data structure in a library, 
> changing its field names is a breaking change.  Downstream 
> users should be able to rely on a library maintainer not doing 
> that except in a major release (and even then, providing a 
> clear heads-up and transition path; it might work in some cases 
> to e.g. rename the struct field but add a `deprecated alias 
> oldName = newName`, and then drop that alias only in the next 
> major release).
>
> If the language design is changed so that downstream users 
> _can_ use named arguments, then library maintainers have to 
> assume that they _will_, and treat parameter names accordingly.
>  It's no good just saying "I don't support this", because if 
> you can't enforce such a constraint ahead of time, you are on a 
> hiding to nothing.
>
> If API opt-in to named parameter support is not adequate, then 
> it's better to drop the feature request entirely, because it is 
> not reasonable to impose a big new responsibility like named 
> arguments on maintainers of existing codebases.

Agree completely. Finally someone arguing from this side :)