>
>
> We already have designated initializers for structs.
>
> One workaround for functions is to define a dedicated struct type with all
> the named parameters and put those into another brace pair.
>
>
>
> If such a type could be created automatically or more simpler?
>
>
>
> - which parameters would go into such a struct? How to specify
>
> - all by reference?
>
> - optimizer would optimize away that type and overhead
>
> - non-default order not allowed with C++ (but with C), perhaps that can
> be made flexible for that auto-generated type
>
> - how to access in function? With base.member syntax? More than one named
> parameter block possible?
>
>
>
> int foo({int param1, float param2} px, char c, {double param3} py)
>
> {
>
> py.param3 ...
>
> }
>
>
>
> foo({.param1 = 5, .param2 = 5.4}, 'a', {1.});
>
>
>
>
>
> Advantage would be that not something completely new has to be introduced.
>

I don't think you can fully avoid that. For D3777, my co-authors and I
discussed the possibility of an auto-generated struct, and it was even the
leading idea for some time, but we eventually dropped it. I would have to
do some digging in our discussion, but as I recall it, there were major
problems:

   - It's not obvious how perfect forwarding could work. We at least want
   to keep the door open for named arguments together with their names, even
   if nothing concrete is part of the initial proposal. IIRC rvalue references
   in structs are always lvalues, regardless of whe value category of the
   access to the struct. This made it questionable how you could forward the
   struct as a whole; either it would do forwarding without ever using
   std::forward/std::move by virtue of passing around an rvalue reference
   in a struct (DANGER!), or ... you couldn't do it at all.
   - A struct is a significant pessimization from an ABI perspective, as
   explained in
   https://eisenwave.github.io/cpp-proposals/named-args.html#abi-and-performance-considerations
   While this would sometimes disappear with inlining, I wouldn't want to
   design a feature that always needs to be inlined (which the user cannot
   really rely on) to not have bad codegen.
   - If you need to change how the function declaration works, it's not
   possible to apply this new feature to existing standard library functions.
   However, that is a big part of the motivation, like avoiding bugs in calls
   to std::lerp or eliminating the vast majority of overload algorithm
   candidates using std::ranges::sort(.exec = e, ...).



>
> -----Ursprüngliche Nachricht-----
> *Von:* codusnocturnus via Std-Proposals <std-proposals_at_[hidden]>
> *Gesendet:* Fr 02.01.2026 23:22
> *Betreff:* Re: [std-proposals] Labelled parameters
> *An:* std-proposals_at_[hidden];
> *CC:* codusnocturnus <codusnocturnus_at_[hidden]>;
>
>
> On Friday, January 2nd, 2026 at 11:49 AM, Jan Schultke via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>
> What about a mixture of positional and named parameters?
>
> I have some thoughts on that here:
> https://eisenwave.github.io/cpp-proposals/named-args.html#mixing-named-and-positional-arguments
> Things can get pretty confusing when mixing of positional and named
> arguments is permitted. The low-hanging fruit is to allow positional
> arguments at the start of the argument list, which has the obvious behavior
> of working exactly like positional arguments normally do.
>
> More recent versions of Kotlin allow you to mix positional and named
> arguments in the middle, but only within a prefix of arguments where if an
> argument is named, it needs to be in the same position as if it was
> provided positionally. For example, f(.first=0, 1) is valid, but f(.second=1,
> 0) is not. However, what Kotlin eventually made valid is unnecessarily
> ambitious for the first version of such a feature.
>
>
> I wonder if the mixed-use use case is a real thing, though? It's clearly a
> question to be addressed, but I imagine that people who want named
> parameters will always use them, and those who don't will never use them
> (unless/until forced).
>
> That said, variadic functions will present an interesting problem or two.
>
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>