On Sun, Jan 4, 2026 at 3:07 AM Jens Maurer via Std-Proposals <
std-proposals_at_[hidden]> wrote:

>
>
> On 1/4/26 08:32, Jan Schultke wrote:
> >
> > Things that you might want to put into the narrative:
> >
> > - Given that several function declarations may have deviating
> > parameter names, choosing which one to take is a question.
> > But that has been conceptually addressed by reflection
> > (take the unique one, otherwise there is none).
> >
> > - Exposure of function parameter names from the standard library
> > is also conceptually addressed by reflection.
> >
> >
> > Yeah, maybe the draft doesn't make it so obvious, but our approach to
> declarations with different parameter names is the same as for parameter
> name reflection.
> >
> > As for standard library functions, they already have a bunch of
> properties that are observable but which we don't bother to keep stable
> like:
> >
> > * Exact expression validity/invalidity (detectable with
> requires-expressions).
> > * Forming function pointers or references to functions (except for
> addressable functions).
> > * Explicitly providing template arguments (in <algorithm>).
> > * Reflecting on parameter names and other properties (although I'm not
> sure we have a policy for this).
> >
> > Furthermore, the parameter names in the implementation all use reserved
> identifiers, and we could recommend a warning when a reserved named
> argument is used, like f(.__x = 0). Consequently, a library-wide policy of
> not supporting named arguments would be trivial to implement.
>
> I have no concern about the outcome; my concern is to make the connection
> to
> reflection decisions in the narrative of the paper, to show the conceptual
> consistency there.
>
> Jens


I think it's pretty likely that keyword arguments would have to be
explicitly opt-in. Standard library implementations use reserved names for
all their parameters, but approximately no other libraries actually do. And
those library's parameter names are, very likely, not considered for
external use — and may not want to be considered as part of the API. This
is a bit different from reflection, since you can't actually *do much* with
the reflected identifiers (except using in bindings, which is super useful)
but now we're talking about use in normal code.

Even when the parameter names are normal-ish, that's probably not something
that library authors want users to rely on. For instance, in range-v3, the
predicates and projections are pretty consistently named pred and proj, but
is that the correct user-facing name? Eric and Casey have never had to
think about this before. max(r, .proj=key) is definitely nicer to read than
max(r, {}, key), but not as nice as max(r, .key=key) (or ".by" or something
else). Lack of explicit opt-in cements a decision that up until now was
never even a known decision.

Swift does this via parameter labels, as distinct from parameter names.
Where the argument label is user-facing but the parameter name is for the
implementation only.

Barry