> I think the overload resolution is a bigger issue than you make it sound.
> How does it interplay with type deductions, constraints priorities, ADL
> etc. when overloaded signatures exists?
>

No, it's really a very small issue. Named arguments can simply be matched
to function parameters by name rather than by position, like positional
arguments. However, this only changes overload resolution in the sense that
some candidates are disqualified and some arguments are provided
out-of-order. This doesn't have any effect on the complicated mechanisms
like forming implicit conversion sequences or determining which candidate
is more specialized. Whether you provide an argument by name or
positionally, this has no effect on implicit conversions, and it doesn't
make a candidate better than another.

There is a more minimal and extremely unambitious form of the proposal
where you need to provide all named arguments correctly positioned, and
then the name is just a "checked comment", but that's probably not worth
the effort. People can already do that with checked code comments, so this
feature wouldn't be providing much value.


> Personally, I am starting to wonder if a named argument function needs to
> be something different from regular functions, one that does not allow
> redeclarations (or at least requires all declarations+definition to have
> the same argument names). Like:
> ```C++
> // position only
> void foo(int bar);
> // named only
> void /*named arguments tag for function*/ foo(int bar) { foo(bar); }
> // alternative idea: automatic 'namify function'
> void /*named arguments tag for function"/ foo(int bar) = default;
> ```
> But this idea would sorta require that you can't mix positional and named
> arguments.
>

Mixing positional and named arguments is extremely common, so being unable
to mix isn't great. There are ways to control whether an argument may be
positional per parameter, or to split the parameter list into a positional
and named section. There are tons of ways to go about it; personally, I
think we need to decide on whether we want an explicit opt-in in the first
place. If not, then speculating about a million possible ways to design the
opt-in is just wasted effort.


> Another thing that I wonder is; how does it play with code quality and how
> does it compare with e.g. strong types?
>

Strong types are never realistically going to happen. I don't want to write

> std::memcpy(std::memcpy_dest_ptr(to), std::memcpy_source_ptr(from), size);

std::to_chars(begin, end, std::to_chars_base(16));

I want to write

> std::memcpy(.dest = to, .src = from, .count = size);
> std::to_chars(begin, end, .base = 16);


Outside of a few select places, I don't see much appetite for creating
countless additional types. In some cases, having some kind of numeric
range type or using std::span would help.