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]
> <mailto: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] <mailto:Std-Proposals_at_[hidden]>
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>