Would named parameters make this problem moot - i.e. defaults are only needed when you have positional parameters, not named parameters.


<https://en.wikipedia.org/wiki/Named_parameter>
Named parameter<https://en.wikipedia.org/wiki/Named_parameter>
en.wikipedia.org<https://en.wikipedia.org/wiki/Named_parameter>
[wikipedia.png]<https://en.wikipedia.org/wiki/Named_parameter>


Thanks,

Robert

On Feb 1, 2023, at 3:55 PM, Andrey Semashev via Std-Proposals <std-proposals_at_[hidden]> 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.

--
Std-Proposals mailing list
Std-Proposals_at_[hidden]
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals