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

[RazvanN]

On Sunday, 17 February 2019 at 21:04:23 UTC, Yuxuan Shui wrote:
> After thinking about the feedback so far, I currently plan to 
> make these changes to this DIP:
>
> * For reordering: I want to step back from reordering. It was 
> add as an after thought, and turns out to be way more involved 
> than I expected, and it is really not part of my goal for this 
> DIP.
>
> * For @named: Since there exist templates like 
> ParameterIdentiferTuple, it shouldn't be hard to write a 
> template to automatically wrap non- at named functions to make 
> them @named. So this really is not a problem.
>
>   If you are not satisfied with this solution (let me know), I 
> have another proposal: @named will still be part of this DIP, 
> but if a function is not annotated with @named, you can still 
> call it with named parameters. If the names mismatch, you get a 
> warning instead of an error. This way, API developers can 
> clearly state their intentions with @named, and don't have to 
> take responsibilities for API breakage caused by parameter 
> rename; OTOH, API users can still call functions with named 
> parameters.

How about this: simply adding the ability to name the argument 
when calling a function? Example:

void rectangle(int width, int height) {}

void main()
{
     rectangle(1, 2);
     rectangle(width: 1, height: 2);
     rectangle(height: 2, width: 1);
     rectangle(width: 1, 2);    // error
}

All 3 function invocations lower to the same function call. Of 
course, naming should be either for all parameters or for none. 
This has the advantage that no code will be broken and naming 
will become optional. This way you have no mangling problems and 
you don't have to add any attributes.

This solution is also easier to implement and easier to 
drop/enhance after we gather some information about where we need 
to go with this.

Cheers
RazvanN