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

[Joseph Rushton Wakeling]

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.