I see the proposal to use the keyword 'default' as argument for function invocation, to explicit express the will to use the default argument, was already proposed multiple times, since https://wg21.link/N1466, and even in last years on this mailing list, e.g.:

https://lists.isocpp.org/std-proposals/2019/11/0708.php
https://lists.isocpp.org/std-proposals/2020/02/0969.php
https://lists.isocpp.org/std-proposals/2023/02/5607.php

Therefore, I guess to have no chance to have it considered, but I learned several points from such past threads.
In particular, on the one hand there is the alternative (still just a proposal) to explicit parameter names,
similarly to struct construction.
Well, IMHO, this also has problems (maybe easily solvable) as for example:

auto f(int x); //declaration
auto f(int y); //re-declaration
auto f(int w){} //definition

// what parameter name to be selected: x, y, or w ? Well, some restrictions may be forced in order to allow using it.

Another structural aspect is that the way overload resolution would change, as it would be based on names instead of just types. Doable, but likely hard to change the mindset in the community. I would not like that much.

On the other hand, mentioned threads also discuss the topic of non-forwardable 'default', as in the example:

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

std::optional<C> t(std::in_place, 2 /*, default, 1*/); //Second parameter of C constructor cannot be forwarded as default.

Well, I do not really want to force discussing again such a 'default', despite I still like it.


Let me move to the second part of the post.
Another keyword that might have been similarly extended is 'delete', aimed at forcing the compiler not to consider further parameters, e.g.:

void f(int, float = 1.); // #1
void f(int);  // #2

f(2, delete); //selects #2 , no ambiguity

Not sure if a syntax like f[1](2); might have been more appealing to force the compiler selecting only overloads with one parameter.
For sure, it may mislead a reader to suppose f is an array of function pointers.

However, such a 'delete' is also not forwardable, so ... no way to get it, similarly to default.


Now, third part of the post, probably a potential proposal for which I ask to focus on during any answer.
Regardless of functions arguments, maybe there is room to consider and discuss using 'default', 'delete', ... and 'auto' for template arguments.

About 'default', I guess it was in the initial proposal of some of the old threads, but the discussion was then focused on function arguments only.

Do you believe that, even for templates, similar concerns and alternatives apply on 'default' (and 'delete') as for functions ?


Here the news for templates: 'auto'.

Have an explicit auto as template argument may have the goal to keep the compiler deducing corresponding parameter while being able to explicit next arguments, e.g.:

template<typename A, typename B, typename C>
void f(A, B, C);

f<int, auto, float>(a, b, c); // 'b' would be the only function argument leading to deduce a parameter type

An interesting extension would support the possibility to specify the number of arguments to match a parameter pack, so that multiple parameter packs may exist in a primary template, something like:

template<typename... T, typename... U>
class A{ /* some definition*/ }; // suppose T types and U types having a different semantic, as types of class data-members

going on:

template<typename... T, typename... U>
A<T..., U...> makeA(T&&... t, U&&... u);

makeA<auto...[2]>(3, 'c', 1.); // T pack will have size '2', therefore deduced as int and char, and U deduced as 1 type: double whereas a simple 'auto' would still lead T pack to the classic behaviour of grabbing all three types.
This seems barely in line with the pack indexing introduced in C++26.

The syntax auto[N] may be considered to be (one design choice only) equivalent to auto N times (comma separated). Well, likely hard to consider that auto...[N] and auto[N] would get to 'N' a different semantic ('N arguments for a single parameter pack' vs 'auto for N parameters'), but some more clearer solution may be discussed (e.g. auto...N for the former, or [N]auto for the latter), this topic is for a second phase of this discussion.

I don't know whether past proposals tried to introduce the alternative of parameter names even for templates as done for functions (e.g. templ<param1: type1>).
Anyway, the idea of a tool to explicit the number of types to match a pack seems interesting.


Fourth part of the post:
A final context for which 'default' and 'delete' can be used is in the initialization list for objects construction, to make it explicit the list of data members for which to use default values or no initialization (for non-class types).
This might increase the readability about the explicit will of the coder, therefore a better support for coding rules, e.g., in safety environments (about default), as better alternative with respect to implict relying on the default values associated to data members.
Different syntax may be proposed:
- a single 'default'/'delete' for each data member, e.g., dataMemberName{default}
- a single list of data members for each of two (default and delete), e.g., default(dataMemberName1, dataMemberName3)
Second solution is more compact but breaks the (non-standard) coding rules requiring for data members the same order as in class definition.
Not sure if 'delete' is appealing here. It would be 'not initialized' for data members, instead of 'not instantiated' for function members.

I guess that 'default' for data-members is not considered evil as for function parameters, otherwise they would not have been introduced in C++11.
Well, I also understand that here we have risk of redundancy compared to the current way to specify default values, but 'delete' would still be an extension to support performance, instead of coding rules.