On 02/02/2023 18:16, Jason McKesson via Std-Proposals wrote:
> On Thu, Feb 2, 2023 at 11:24 AM Sebastian Wittmeier via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
>>
>> Jason,
>>
>> couldn't your closest solution be implemented as of today?
>>
>> As a separate default argument feature.
>>
>> Using a templated type as arguments, which can be constructed from defaultarg or implicitly from the template parameter type?
>>
>> To convert this type back the final function would have to provide the default value during usage (as an argument to the member function call on the final function argument) in its body instead of being in the declaration.
>
> That's called `std::optional<T>`, with `std::nullopt` being the
> "default value" you pass. It's a thing you can do right now, and it's
> a thing that has inherent advantages over language-based default
> parameters. The most notable of which is that, because the default
> value is not in the function declaration, the default value can be
> changed *without* forcing everyone to recompile their code.
>
> Now, specialized functionality like `source_location::current`'s
> interactions with default parameters is a problem with this approach.
>
> In any case, making this some kind of "separate" feature misses the
> entire point I'm trying to make. Right now, it's nearly impossible to
> build a function that does not allow perfect forwarding, and even in
> the event of those edge cases, there is little incentive to use them
> (`source_location::current` notwithstanding). Therefore, perfect
> forwarding is *reliable*, and we have dozens of standard language APIs
> that rely on it.

I'm going to disagree here, "perfect" forwarding is very far from
perfect, and I wouldn't call edge cases to be very rare. In particular
you can't forward:

1. prvalues
2. initializer lists
3. overload sets
4. literal 0 as null-pointer constant

Out of these probably initializer list is the most common, as you can
probably call most functions with an initializer list for one of the
arguments, but you can't forward that interface.

Having said that I don't think we should add yet an other case to the
list. I wish perfect forwarding were fixed though, and then maybe it
wouldn't be a problem to add `default` as a possible argument.

>
> The feature as proposed *creates* an incentive to design APIs that
> cannot provide perfect forwarding. This causes perfect forwarding to
> be less reliable as a feature. This is bad, and I would say that such
> an eventuality is worse than being unable to design functions that
> take lots of default parameters.

Cheers,
Lénárd