Email Signature

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

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

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@lists.isocpp.org> wrote:

On Fri, 2 Jan 2026 at 19:55, Sebastian Wittmeier via Std-Proposals
<std-proposals@lists.isocpp.org> 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@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals