DIP 1020--Named Parameters--Community Review Round 1

[bauss]

On Monday, 8 April 2019 at 16:33:36 UTC, Yuxuan Shui wrote:
> On Monday, 8 April 2019 at 13:31:48 UTC, bauss wrote:
>> On Monday, 8 April 2019 at 10:10:14 UTC, Yuxuan Shui wrote:
>>> On Sunday, 7 April 2019 at 21:19:20 UTC, Walter Bright wrote:
>>>> On 4/7/2019 10:14 AM, Yuxuan Shui wrote:
>>>>> this proposal seems to mandate the inclusion of parameter 
>>>>> names in mangled name of functions.
>>>>
>>>> Nope.
>>>
>>> OK, I probably misunderstood, but what happens in the 
>>> following case?
>>>
>>> void fun(int a, int b) {...}
>>> void fun(int c, int d) {...}
>>>
>>> fun(c:1, d:1);
>>>
>>>
>>> Is it ambiguous? Or does it invoke the second function? If 
>>> the latter, then you have to include the parameter names in 
>>> mangled name.
>>
>> That wouldn't work because the compiler would reject your 
>> function definitions when you attempt to call either of them 
>> because they're ambiguous.
>>
>> Just like it is today.
>>
>> Basically you could look at them just being:
>>
>> void fun(int,int);
>> void fun(int,int);
>>
>> When you call a function like:
>>
>> void fun(int a, int b);
>>
>> ...
>>
>> fun(a: 1, b: 2);
>>
>> the compiler would really just reorder the passed values to 
>> match the parameters (If they can be specified in any order, 
>> if not then it will just them as it is.
>>
>> Which means:
>>
>> fun(a: 1, b: 2);
>>
>> becomes:
>>
>> fun(1, 2);
>>
>> and by then it should be clear why it wouldn't be allowed nor 
>> would work at all.
>
> Yes, what you said _could_ be the case. But it's not 
> immediately clear from Walter's proposal, that's why I would 
> prefer a direct answer from him.
>
> Quoting from Walter's proposal:
>
>> I.e. function resolution is done by constructing an argument 
>> list separately for each function before testing it for 
>> matching. Of course, if the parameter name(s) don't match, the 
>> function doesn't match.
>
> From that, it sounds like fun(c:1,d:1) shouldn't match fun(int 
> a, int b). That's why I asked that question.
>
> The interpretation of his proposal suggested by you (i.e. this 
> call is ambiguous) is obviously a possible one, but not 
> necessarily what Walter intended.

No it wouldn't match that BUT the compiler would reject that 
regardless of named parameters being implemented or not.

See:

void fun(int a, int b) {...}
void fun(int c, int d) {...}

Which fun am I calling here?

fun(1,2);

The same issue would exist with named parameters even with 
Walter's proposal and there would be no way to resolve it unless 
the mangling of the function contained the parameter names which 
Walter said they wouldn't.

And in that case it doesn't matter really because it's not a 
situation that would ever happen.