You are right. Regardless, a default arg can't cause a compile time error
either.

On Mon, Feb 3, 2020 at 1:01 PM Avi Kivity <avi_at_[hidden]> wrote:

> This should cause a compile error as the overloads collide.
> On 02/02/2020 19.24, Михаил Найденов wrote:
>
> Adding a default will change existing calls
>
> void f(int x, int y, int z, int a=0);
> f(1, 2, 3); //< assigns a, y, z
>
> At some point in the future
> void f(int x, int y=4, int z, int a=0);
>
> f(1, 2, 3); //< silently changes to assigning x, z, a, because there is
> now an explicit overload void f(int x, int z, int a);
>
>
> On Sun, Feb 2, 2020 at 6:36 PM Avi Kivity via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>> Currently, default arguments to functions must be trailing; "void f(int
>> x = 4, int y)" is not allowed.
>>
>>
>> I propose to relax this. The main motivation is that a trailing lambda
>> argument is readable, while a lambda argument inside a longer parameter
>> list is not.
>>
>>
>> Readable:
>>
>>
>> f(5, foo, bar, [baz] {
>>
>> baz->shoo();
>>
>> });
>>
>>
>> Less readable:
>>
>>
>> f(5, [baz] {
>>
>> baz->shoo();
>>
>> }), foo, bar);
>>
>>
>> So, there is competition for the last slot of the argument list.
>>
>>
>> To implement this, the compiler generates overloads for each default
>> parameter combination.
>>
>>
>> void f(int x = 4, int y);
>>
>> is translated to
>>
>>
>> void f(int x, int y);
>>
>> void f(int y) { f(4, std::forward<int>(y)); }
>>
>>
>> Functions with many non-trailing default arguments may generate many
>> combinations; some of them may be ambiguous, which the compiler should
>> diagnose.
>>
>>
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>
>