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

[Yuxuan Shui]

On Friday, 15 February 2019 at 14:23:06 UTC, Paul Backus wrote:
> On Friday, 15 February 2019 at 12:56:45 UTC, Mike Parker wrote:
>> This is the feedback thread for the first round of Community 
>> Review for DIP 1019, "Named Arguments Lite":
>
> [snip]
>
> I understand that the intent is to avoid unintentional 
> breakage, but this feature is already opt-in from the caller's 
> side. If someone wants to write code that's robust against 
> parameter name changes, they can do it by not using named 
> arguments in the first place.

Named parameters have to be opt-in at both sides.

For the caller side, they can choose to not call the function 
with names so they can be robust against name changes (as you 
said).

For the callee side, opt into named parameter create extra 
responsibility for them (e.g. they need to create new prototypes 
if they want to change parameter names). So if they don't want 
this responsibility, they can choose to not opt-in

> And, as noted in the DIP itself, there are still opportunities 
> for accidental breakage even with @named, when the caller fails 
> to re-compile their code after a parameter name change.

I am not quite sure what you mean by this. A name change either 
changes the semantic of the parameters, in which case the caller 
won't realize their is a breakage until they recompile. But this 
kind of breakage is always intentional from the callee side. A 
pure parameter name change won't break anything even if caller 
doesn't recompile.

>
> Parameter lock-in is definitely a legitimate concern, but IMHO 
> adding a neutered version of named arguments like this one to 
> the language would be worse than not having named arguments at 
> all.

If someone doesn't like this, they can come up with a DIP to 
deprecate the @named attribute in the future.