I like the idea of the idea but there are multiple problems with the
function parameter naming scheme, with or without default parameters.

Something like this was potentially suggested foo(x=1,y=2.2). What if the
parameter name conflicts with a local identifier name. Did you just set
the local variables x to 1 and y to 2.2 or are you using the
parameter name. I don't think parameter naming is viable, but if it were
to be used, you would need to use something like a dot name (similar to
named parameters structure initialization), to differentiate parameter
names from locals.

Given:
void foo(int y, double x);
void foo(double x, int y);

void foo(int x, double y) {}
void foo(double y, int x) {}

What function would foo(.x=1,.y=2.2) call?

OR given:
void foo(int y, double x);
void foo(double x, int y);

What function would foo(.x=1,.y=2.2) call?

void foo(int x, double y) {}
void foo(double y, int x) {}

Function prototypes do not need names and if they do have names the name
does not need to be consistent with the actual implementation and the
implementation does not need to be known where the function is called.
Function parameter names are not part of what makes function signature
unique nor included in any mangling. Plus I do not like binding external
code to an internal implementation. You have no idea who will be the
consumer of this code (especially in the case of a library). You could
break client code by changing your function's internal naming.

I think that we have to stick with function signatures by type and order
not names.



On Mon, Mar 7, 2022 at 12:03 PM Jason McKesson via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On Mon, Mar 7, 2022 at 1:07 PM Hani Deek via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
> >
> > I love your proposal, because it can save tons of code. It allows us to
> use the brief syntax of default arguments instead of having to write
> multiple function overloads to supply missing argument values that are not
> trailing arguments.
> >
> > However, whenever you suggest something that has the effect of
> drastically reducing the amount of required code, people will object on the
> grounds that your suggestion opens the door for misinterpreting typos and
> unintended mistakes.
> >
> > Naturally, the less you write, the less clear your intention becomes.
> >
> > C++ generally gives favor to typo/mistake avoidance over brevity,
> although occasionally there were changes that violated this principle, such
> as the 'Down with typename' proposal of C++20. I love the fact that that
> proposal was adopted because it has allowed us to avoid many unnecessary
> uses of the 'typename' keyword, but that proposal went against the usual
> direction of C++.
>
> I would say that this is a mischaracterization of both that proposal
> and the general direction of C++.
>
> `typename` was not added to the language to avoid user mistakes. It
> was added as a *syntactic necessity* for compilers in certain
> situations when using dependent names. Compilers have to know what
> kind of thing a name is, and they cannot know that if the text leading
> to said name depends on a template parameter. It can only be known
> after template substitution. But C++ is not a context-free grammar;
> certain aspects of the grammar depend on knowing if a name is a
> variable, typename, or template. The compiler needs clarification;
> hence `typename`.
>
> The "Down with typename" proposal removed using `typename` from places
> where the fact that a particular dependent name is a typename is
> *known* through context. Some name `X` might be dependent and unknown,
> but if it appears in `using name = X;`, there is no question that `X`
> must be a typename. That's how `using` directives work. The compiler
> doesn't need to be told what it is, so the proposal made it
> unnecessary.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>