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:
>>> On 2/1/23 17:25, Bo Persson via Std-Proposals wrote:
>>>> On 2023-02-01 at 14:22, Andrey Semashev via Std-Proposals wrote:
>>>>> On 2/1/23 16:19, Bo Persson via Std-Proposals wrote:
>>>>>> On 2023-02-01 at 13:56, Andrey Semashev via Std-Proposals wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> Would it be possible to be able to explicitly specify default
>>>>>>> arguments
>>>>>>> for template specializations and function calls?
>>>>>>>
>>>>>>> void foo(int x, int y = 10, int z = 20);
>>>>>>>
>>>>>>> foo(1, default, 3); // == foo(1, 10, 3);
>>>>>>>
>>>>>>>
>>>>>>> // Use default ordering function
>>>>>>> typedef std::set< int, default, my_alloc > my_set;
>>>>>>>
>>>>>>> // Use default compare and hash functions
>>>>>>> typedef std::unordered_set< int, default, default, my_alloc >
>>>>>>> my_uset;
>>>>>>>
>>>>>>>
>>>>>>> template<
>>>>>>> typename T,
>>>>>>> typename = whatever,
>>>>>>> bool = is_special< T >::value
>>>>>>> >
>>>>>>> struct trait {};
>>>>>>>
>>>>>>> // Specialization: trait< T, whatever, true >
>>>>>>> template< typename T >
>>>>>>> struct trait< T, default, true > {};
>>>>>>>
>>>>>>> This syntax is currently invalid, so the extension would be pretty
>>>>>>> harmless. This would allow to avoid code duplication, where the
>>>>>>> user of
>>>>>>> the function or template, or the one who specializes the template,
>>>>>>> has
>>>>>>> to duplicate the default argument when he only needs to specify the
>>>>>>> arguments after that.
>>>>>>
>>>>>> This seems to have been proposed 20 years ago.
>>>>>>
>>>>>> https://wg21.link/N1466
>>>>>>
>>>>>> Didn't go anywhere.
>>>>>
>>>>> Any particular reason why it got rejected or it was simply abandoned?
>>>>>
>>>>
>>>> It's too long ago, I don't remember.
>>>>
>>>> One argument could be that there are several ways around the limitation.
>>>>
>>>> Like if the arguments are not all of the same type, you can have
>>>> overloads with fewer arguments that forwards to the full function.
>>>
>>> Obviously, this would complicate maintenance as you'd have to provide
>>> all permutations of the specified/not specified optional arguments.
>>
>> In the example we only have three parameters, and occationally want to
>> skip the middle one. That't only one permutation.
>>
>>
>>> 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.

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.