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.

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.