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.   -----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