On Wed, Feb 1, 2023 at 8:46 PM Andrey Semashev via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> On 2/2/23 04:24, Jason McKesson via Std-Proposals wrote:
> >
> > It's interesting that you bring up perfect forwarding. Because
> > forwarding pretty much kills this idea (and most forms of named
> > parameters.
> >
> > That is, if you want `T t(1, default, 5);` to work, how do you propose
> > to make `optional<T> t(std::in_place, 1, default, 5);` work? Or better
> > yet, `std::thread thr(some_functor(), 1, default, 5);`?
>
> I do not propose to make that work. The proposal is just to be able to
> write "default" for arguments that have a default, nothing more. This is
> not intended to work across an abstraction layer such as std::thread,
> std::bind, std::optional, function pointers, etc.
>
> > The closest I could come up with is that the expression `default` is a
> > prvalue of some `nullptr_t`-style type.
>
> `default` would not be an expression in a full sense. It would be a core
> language placeholder that is replaced by the default argument
> expression. That is:
>
> template< typename T >
> void foo(T const& str = "Hello");
>
> foo(default); // literally equivalent to foo("Hello");,
> // which makes T be char[6].
>
> Just to be clear, if `default` is used for an argument without a
> default, the program is ill-formed (same as when you don't specify an
> argument that doesn't have a default).
>
> > Which opens up a whole new can of worms regarding overload resolution
> > and function selection. Plus, there's the fact that "has a default
> > parameter" is not an innate property of a function; it's just
> > something that a particular declaration happens to have.
>
> Per the above, overload resolution is unaffected, since the call is
> functionally equivalent to the caller not specifying the argument at all.
>
> > I would argue that if you cannot solve the forwarding problem for
> > default parameters, then you're basically un-perfecting perfect
> > forwarding (not that it's actually perfect as is, but it's not nearly
> > this bad). And that's not worth the gains of being able to default
> > parameters.
>
> I'm not sure why you think that default argument values need to be
> forwarded - this is not possible now, and it was not my intention to
> support it with this proposal.

You can combine forwarding and default parameters just fine today:

```
struct C
{
  C(int, float = 5.0f);
};

std::optional<C> t(std::in_place, 2); //Second parameter is defaulted.
```

If you're creating a new mechanism for calling functions, it ought to
be able to work with forwarding too. And if it can't be forwarded,
then maybe it doesn't need to exist.

Or to put it another way, forwarding matters *way more* than
defaulting parameters.