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

[jmh530]

On Tuesday, 10 September 2019 at 18:41:50 UTC, rikki cattermole 
wrote:
> [snip]
>
> Actually right now I think DIP 1020 has the potential to have 
> breakage from the change of API named parameter names. It alone 
> provides no tools to deal with it.
>
> Apart from designing a little defensively, I am not taking a 
> stance on this problem in the DIP. But I think I should 
> consider what you are saying. I think there is something I 
> should take note of here but I'm not sure what it is just yet.


I would think that this issue would affect any named parameter 
DIP. Library users would need to rely on the parameter names not 
changing if they make use of them. The most common tool would be 
grep. There's no reason that library authors couldn't use a 
deprecation period where they add another parameter to the 
function with the new name and have the old named one forward to 
it.

Also, the DIP has a section about the review and includes a 
mention to Walter's suggestion, but I don't really see an 
explanation of why this DIP is better than his suggestion. In 
general, I like the idea of named parameters, but I find his 
version more parsimonious until convinced otherwise.