On 05/01/2026 13:38, Jens Maurer wrote:
>
> I think we want to be ABI-stable when enabling a function to
> be called with named parameters, during code evolution.
> Anything involving extra layers of types likely doesn't do that.
>
> And I agree with Ville that named parameters need to be opt-in,
> i.e. the function declaration should expressly indicate that
> something can be called with named parameters (and thus the
> chosen parameter names are promised to be stable).
>
>
> Before, in some library (not necessarily the standard library):
>
> void f(int x, bool y);
> // not the best names, but not really an issue; can be fixed
> // by the library at any time without disturbing callers
>
> After migrating to C++xy with named parameters and upgrading the
> library API to allow for a nicer call syntax:
>
> /* marker */ void f(int nitems, bool allocate);
>
> This "after" transition step marks the spot where the library author
> promises stable parameter names going forward. (And hopefully has
> given some thought to those names.)
>
> Now, there were also feature requests asking for some form of mixed
> positional / named parameters; if that's not just a choice by the
> caller, but also a feature choice of the function declaration, then
> the opt-in marker might naturally appear at the boundary between
> positional and named:
>
> void f(/* marker */ int nitems, bool allocate); // both are named parameters
>
> Jens
>

It would be simpler to say here that "marker" allows you to use named
parameters, but does not require it. Thus after a declaration with
"marker" you can call the function with positional arguments, named
arguments, or a mixture. (You would probably disallow positional
arguments after any named arguments.) I am not sure it is worthwhile to
have a way to /force/ the use of named arguments. You can always use
strong types when you want to require named arguments in some way - the
most obvious use-case being when a function takes several bool flags
that could be replaced by scoped enums.