On 2/2/23 18:03, Jason McKesson via Std-Proposals wrote:
> On Thu, Feb 2, 2023 at 5:12 AM Andrey Semashev via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
>>
>> On 2/2/23 06:58, Jason McKesson via Std-Proposals wrote:
>>>
>>> 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.
>>> ```
>>
>> The last parameter not defaulted in `std::optional<C>` constructor, that
>> is, its signature does not have a `float` argument. In this sense, it is
>> not forwarded, and it stays that way with the proposed addition of
>> explicit `default` arguments. Yes, you cannot use explicit `default` in
>> a case like this, but I don't see a problem with it.
>
> You don't see a problem with `T t(5, default);` being legal but
> `optional<T> t(in_place, 5, default)` not being legal? In essence,
> you're saying that the following, or any equivalent, is just not
> reasonable code to write:
>
> ```
> template<typename T>
> auto passthru(int i) requires requires { T t(5, default); }
> {
> return optional<T>(in_place, 5, default);
> }
> ```
>
> Just from a feature usability standpoint, you consider it acceptable
> that `make_shared`, `make_unique`, `thread`, and dozens of similar
> functions are just completely incompatible with this feature, despite
> default parameters as they currently exist working with all of them
> presently.

Yes, I find this acceptable. Ideally, I would like this to work, but my
world doesn't end if it doesn't and I would still find this feature
plenty useful as currently proposed. In fact, my original post was
provoked by a yet another instance where I would've gladly used this
feature in a real world code.

>>> 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.
>>
>> I don't think it is fair to say one feature is more important than the
>> other, as those are distinct features that are used in different
>> contexts and each one is useful on its own. That is, we use default
>> arguments without forwarding and forwarding without default arguments
>> all the time, and I don't see why improving default arguments without
>> also benefiting forwarding is such a bad idea.
>
> A good language is one that makes sense, where features interact in
> reasonable ways. C++ doesn't always do this, but it is an unalloyed
> good. We don't *always* use forwarding with default arguments, but
> that option is *always available* should we need it.
>
> You want to change the language so that it is only conditionally
> available. That is... short-sighted at best.

The change I'm proposing makes a certain class of use cases better. Not
as wide class of use cases as you'd prefer, but better nonetheless. The
alternative is, of course, to do nothing just because those other use
cases are not supported by this proposal. I wouldn't say this
alternative is any helpful.