IMO the std::label approach is very ugly

Ideally I would just be able to do:
void* memcpy( void* dest, const void* src, std::size_t count );
memcpy(.dest = foo, .src = bar, .count = baz);
IMO might as well use the same syntax as designated initializers

What would make sense to me:
GIven a function call, some arguments are regular (positional), while some
are designated-initializer-esque (named)
All positional arguments must appear before all named arguments
memcpy(.src = bar, foo, .count = baz); // ill-formed

If a function has multiple declarations, and they are not identical in
naming of parameters,
then it is implementation defined whether or not a function call using
named parameters is ill-formed or well-formed.
If it is well-formed, it should be interpreted as-if one specific
declaration was visible, implementation can choose which one.

int foo(int x, int y, int z);
int foo(int y, int x, int z);
foo(.x = 1, .y = 2, .z = 3); // can be ill-formed, or foo(1,2,3) or
foo(2,1,3)

With this it is not intended for the compiler to flip a coin and pick a
declaration, but to make a smart choice
when one is available, and ill-formed when one is not.
For example, implementations might introduce a [[primary_declaration]]
attribute for this.

Order of construction is as unspecified as regular function calls.

Unsure about variadic parameters.
Might need Generalized pack declaration and usage
<https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p1858r2.html>
void foo(int foo, auto... bar, int baz);
foo(.foo = 1, .baz = 2, .bar = ...{1, 2, 3});

Unsure on overload resolution.
One (IMO natural, but unsure optimal in practice) possibility is:
void foo(int x);
void foo(char);
foo(.x = 1); // finds first overload
foo(.x = 'a'); // still finds first overload, 2nd can't be used with named
params

What about forwarding/passthrough APIs?
void function(int a, int b, int c);
void wrapper(auto... args) {
  std::println("called");
  function(args...);
}
function(.a = 1, .b = 2, .c = 3); // works
wrapper(.a = 1, .b = 2, .c = 3); // makes no sense

Obviously not the way it is implemented here, but should some easy approach
exist?
This might be doable via function parameter reflection and Code Injection
with Token Sequences
<https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3294r2.html>
Unsure
Also unsure how important this is to consider

On Fri, Jan 2, 2026 at 6:58 PM Ville Voutilainen via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On Fri, 2 Jan 2026 at 19:55, Sebastian Wittmeier via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
> > Probably one can run AI for feedback (even that is questionable).
> > But to fill the cracks = to directly incorporate AI output into parts of
> the proposal - is definitely forbidden by ISO.
>
> Can we please not waste time on debating "AI" nonsense on this thread
> too, thanks.
>
> I know how to construct that proposal. I do not need LLMs to do that.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>