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@scylladb.com> 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@lists.isocpp.org> 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@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals