On 2/2/23 00:59, Bo Persson via Std-Proposals wrote:
> On 2023-02-01 at 21:55, Andrey Semashev via Std-Proposals wrote:
>> On 2/1/23 22:18, Bo Persson via Std-Proposals wrote:
>>> On 2023-02-01 at 16:39, Andrey Semashev via Std-Proposals wrote:
>>>
>>>> Remember when we didn't have perfect forwarding in the core language?
>>>
>>> But we do now. So let's use it.
>>
>> My point was that trying to work around this problem through adding
>> overloads will lead to overload explosion similar to what we had when we
>> had to implement perfect forwarding in C++03.
>
> But now that we have perfect forwardning, we can use that to simplify.

It won't relieve you from adding function overloads, so it doesn't
simplify anything.

> And I could also live with the workaround of having to occationally use
>
> foo_with_default_y(1, 3); // or a better domain dependent name
>
> instead of
>
> foo(1, default, 3);
>
> Just arguing that I see a language change as a high cost for something
> that *I* would hardly ever use. YYMV.

I don't dispute that you can work around the problem. I argue that I'd
rather not have to work around it. We could work around perfect
forwarding, variadic templates and lambda functions in C++03, and yet
the language was extended to support these use cases natively.

I consider adding an overload like you suggested is a worse solution to
using the default keyword because it makes foo definition more expensive
- the more significantly expensive the more there are default arguments.
You have to duplicate the default arguments in foo_with_default_y
definition, and any other foo overloads you might add. Changing the
default becomes more difficult as you have to update all instances where
it is specified. And you'd have to do this sort of work for every
function that has default arguments where you may want to leave some of
them default at the call site. Whereas the default keyword provides the
ability to specify default arguments "for free", without having to write
any additional code, and with minimal required work in case if you want
to change the default value in the future.

Lastly, this still doesn't address other use cases, e.g. with template
arguments.