On 4/7/2019 1:31 AM, rikki cattermole wrote:
> That solves function arguments, what is your proposal for templates?

Same problem, same solution.

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.

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.

The compiler will directly reject...

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

...  before you even try to call 'fun'.

On Monday, 8 April 2019 at 10:41:25 UTC, Daniel N 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.
>
> The compiler will directly reject...
>
> void fun(int a, int b) {...}
> void fun(int c, int d) {...}
>
> ...  before you even try to call 'fun'.

Contrary to popular belief, it won't.

https://d.godbolt.org/z/Bmc-Qb

On Monday, 8 April 2019 at 12:01:39 UTC, Yuxuan Shui wrote:

[..]


>> The compiler will directly reject...
>>
>> void fun(int a, int b) {...}
>> void fun(int c, int d) {...}
>>
>> ...  before you even try to call 'fun'.
>
> Contrary to popular belief, it won't.
>
> https://d.godbolt.org/z/Bmc-Qb


In line with popular belief it will. Try calling 1 of the 2 functions i.e.:

int x = fun(3,4);

You have to call one of them for the compiler to be (un)able to resolve the call.

On Monday, 8 April 2019 at 13:11:51 UTC, ShadoLight wrote:
> On Monday, 8 April 2019 at 12:01:39 UTC, Yuxuan Shui wrote:
>
> [..]
>
>
>>> The compiler will directly reject...
>>>
>>> void fun(int a, int b) {...}
>>> void fun(int c, int d) {...}
>>>
>>> ...  before you even try to call 'fun'.
>>
>> Contrary to popular belief, it won't.
>>
>> https://d.godbolt.org/z/Bmc-Qb
>
>
> In line with popular belief it will. Try calling 1 of the 2 functions i.e.:
>
> int x = fun(3,4);
>
> You have to call one of them for the compiler to be (un)able to resolve the call.

Yes. But the post I was replying to says: "The compiler will directly reject...  before you even try to call 'fun'.", which is not true.

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.

On Monday, 8 April 2019 at 13:31:24 UTC, Yuxuan Shui wrote:
> On Monday, 8 April 2019 at 13:11:51 UTC, ShadoLight wrote:
>> On Monday, 8 April 2019 at 12:01:39 UTC, Yuxuan Shui wrote:
>>
>> [..]
>>
>>
>>>> The compiler will directly reject...
>>>>
>>>> void fun(int a, int b) {...}
>>>> void fun(int c, int d) {...}
>>>>
>>>> ...  before you even try to call 'fun'.
>>>
>>> Contrary to popular belief, it won't.
>>>
>>> https://d.godbolt.org/z/Bmc-Qb
>>
>>
>> In line with popular belief it will. Try calling 1 of the 2 functions i.e.:
>>
>> int x = fun(3,4);
>>
>> You have to call one of them for the compiler to be (un)able to resolve the call.
>
> Yes. But the post I was replying to says: "The compiler will directly reject...  before you even try to call 'fun'.", which is not true.

Yes, I agree he could have stated that better. But I'm pretty sure he meant something like "the compiler will directly reject... _once_ you even try to call 'fun'" or similar.

BTW, this is the same in C++.

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.

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.