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

[Yuxuan Shui]

On Sunday, 17 February 2019 at 17:58:56 UTC, Rubn wrote:
> On Sunday, 17 February 2019 at 17:09:57 UTC, Yuxuan Shui wrote:
>> On Sunday, 17 February 2019 at 13:12:11 UTC, Rubn wrote:
>>> [...]
>>
>> This is allowed, _right now_. This is not an addition made by 
>> this DIP. Example: https://d.godbolt.org/z/hbwsaU
>
> Yes that's very different from what you want to implement it. 
> See below.
>
>>> [...]
>>
>> And they have the problem that the name of the parameter 
>> becomes part of the API. This is something this DIP tries to 
>> solve.
>>
>>> [...]
>>
>> I am pretty sure this DIP listed some major languages with 
>> this feature, and it also includes concrete examples.
>
> Yes and Python doesn't behave the way you are suggesting. 
> Listing the languages that implement the feature but not how 
> they implement it makes the argument weaker. You list Python 
> but I would not say Python implements this feature the same way 
> as you are suggesting it to be implemented. I'd use Python as 
> an example against this DIP (as I have).
>
> Eg the DIP suggests this be valid code so long as it can be 
> distinguished by at least one parameter.
>
>     @named:
>     int add(int a, int b) { ... }
>     int add(int c, int d) { ... }

This is not valid under this DIP.

Actually, this is allowed under current D too, as long as you 
don't call "add". With my DIP, the behavior is the same, when you 
call add, you will get an error because your call matches both 
function. Parameter name is not part of overload resolution, this 
is explicitly stated in the DIP.