DIP 1020--Named Parameters--Community Review Round 2
john.michael.hall at gmail.com
Tue Sep 10 20:08:38 UTC 2019
On Tuesday, 10 September 2019 at 18:41:50 UTC, rikki cattermole
> 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
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.
More information about the Digitalmars-d