What about a mixture of positional and named parameters?


On 1/2/26 14:39, Ivan Lazaric via Std-Proposals wrote:
> 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
>
>

-- 
Email Signature
Fornux Logo <https://www.fornux.com/>  
*Phil Bouchard*  LinkedIn Icon 
<https://www.linkedin.com/in/phil-bouchard-5723a910/>
Founder & CEO
T: (819) 328-4743
E: phil_at_[hidden]| www.fornux.com <http://www.fornux.com>
720 Oliver Ave, San Diego, CA, 92109
The Best Predictable C++ Memory Manager 
<https://static.fornux.com/c-superset/> Le message ci-dessus, ainsi que 
les documents l'accompagnant, sont destinés uniquement aux personnes 
identifiées et peuvent contenir des informations privilégiées, 
confidentielles ou ne pouvant être divulguées. Si vous avez reçu ce 
message par erreur, veuillez le détruire.
This communication (and/or the attachments) is intended for named 
recipients only and may contain privileged or confidential information 
which is not to be disclosed. If you received this communication by 
mistake please destroy all copies.