DIP 1030--Named Arguments--Community Review Round 1 Discussion

[jmh530]

On Monday, 10 February 2020 at 21:41:02 UTC, Manu wrote:
> [snip]
>
> It's a huge problem today when a bad choice of function name is
> calcified; we'll be multiplying the probability of making bad 
> naming
> choices by 2-3x.
> We can correct a bad function name by renaming it and producing 
> a
> deprecated alias for the old name. We have no such way to 
> correct a
> change in parameter name; we can't use alias because the 
> parameter
> names are not part of the signature.
>
> Don't ignore the material issue I've shown that demands one of 
> the 2
> responses I suggested.
> If you push for acceptable of this DIP, then I think you must 
> have a
> response to my primary issue.

I was leaning towards favoring this DIP, as I frequently use 
named arguments in R and like the flexibility they offer in some 
cases. However, I came across two functions, written in python, 
at work. One takes a parameter and the other takes a slightly 
different parameter name. No good reason why these two do not use 
the same parameter names. They should be the same. However, 
python has named arguments for everything, so changing the names 
would mean that any code that uses the named version breaks. It 
definitely would make people much more conservative about 
changing their functions.