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

[Rubn]

On Sunday, 17 February 2019 at 20:58:04 UTC, Yuxuan Shui wrote:
> 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.

How does it decide which function to call in this case, straight 
from the DIP, go through the entire process cause the DIP is 
rather ambiguous. Specifically if parameter names are not 
included in the mangled name of a function per the feature not 
being part of the scope of the DIP.

> int add(int a, int b) {...}
> int add(int c, int d) {...} // not in the overload set
> void main() {
>     add(a: 1, b: 2);
> }
>
> It might be useful to have parameter names included in the 
> mangled name of a function so that changing the ordering of 
> parameters does not break existing binaries. Such is beyond the 
> scope of this DIP. A future DIP may address this issue.