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.   Sebastian   -----Ursprüngliche Nachricht----- Von:Jason McKesson via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Do 02.02.2023 02:25 Betreff:Re: [std-proposals] Explicitly specifying default arguments An:std-proposals_at_[hidden]; CC:Jason McKesson <jmckesson_at_[hidden]>; On Wed, Feb 1, 2023 at 10:39 AM Andrey Semashev via Std-Proposals <std-proposals_at_[hidden]> 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. > Remember when we didn't have perfect forwarding in the core language? 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);`? The closest I could come up with is that the expression `default` is a prvalue of some `nullptr_t`-style type. Values of this type can be created, copied, stored, etc just like `nullptr_t`. But it is otherwise inert; unable to be converted into any other type. Unless of course you pass such a valueit as a parameter to a function; if that function takes a default parameter, then it initializes the parameter with the default value. 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. 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. -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals