Discussion Thread: DIP 1030--Named Arguments--Final Review

[jmh530]

On Wednesday, 13 May 2020 at 00:37:51 UTC, Walter Bright wrote:
> We already have named arguments in D since the very beginning - 
> the struct initialization syntax.
>
> Not a single person has complained about breakage when 
> implementers changed the names of the struct fields.
>

I personally do not use this feature very much. I would expect 
named arguments for functions to be used significantly more.

> This is similar to:
>
> 1. what happens if the implementer changes the types of the 
> parameters?
>
> 2. what happens if the implementer changes the order of the 
> parameters?
>
> Then user code breaks.
>
> If anything, this feature will motivate implementers to take 
> some care to name the parameters appropriately.

One reason why python supports positional-only arguments is 
interacting with C. Suppose there is a C library that you 
generate a wrapper for automatically. At some later point, the C 
library changes some names of parameters. If we generate a new 
wrapper for D, then any place where you called these functions 
with named parameters would break (I believe the alternative 
would be to remove the names from extern(C), but I believe there 
are reasons why people don't usually do this). This would have an 
impact on people who call C from D, but the C implementer would 
not change their behavior based on this DIP.

Alternately, suppose an implementer does want to change the name 
of some parameters, for whatever reason. The only thing I can 
think of is deprecating the old function, then eventually 
removing the old version and replacing it with a version with the 
parameter name changed. I don't see anything in the DIP that 
would suggest that both versions could be used at once. For 
instance, nothing in the DIP would suggest that the following 
would compile:

deprecated void foo(int x, int a) {}

void foo(int x, int b) {}

void main()
{
     foo(1, b:2);
}