I do want to point out that I do have a "named parameter library" for C++
here: https://github.com/doocman/dooc-np
It is a bit rough around the edges and makes the declaration of functions
quite ugly, but if you want, I can try to help with that paper. A
disclaimer though: I found the "string indexed tuple" more useful in
projects than the named parameters itself that exists in the library as it
enabled a limited but useful reflection capability.

// Robin

On Sat, Jan 3, 2026, 05:03 Jan Schultke via Std-Proposals <
std-proposals_at_[hidden]> wrote:

>
>> 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
>>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>