On Mon, Jan 5, 2026, 9:13 AM Ville Voutilainen via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On Mon, 5 Jan 2026 at 16:39, Jan Schultke via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
> >>
> >> Unfortunately, the answer is yes, it is apparently too much to ask.
> >>
> >> Like many features that are available in modern languages but missing,
> >> complicated or ugly in C++, named parameters can be easily and
> >> consistently supported in a language when they are designed in from the
> >> start. Finding a syntax for named parameters is easy - finding a way to
> >> add them to the existing language without breaking compatibility, ABI's
> >> and existing code, and doing so in a manner that fits the rest of the
> >> language now and in the future - that's the hard part.
> >
> >
> > When you say it's too much to ask, you're saying that the C++ equivalent
> of the Kotlin sample I've shown is just fundamentally infeasible at this
> point? That is:
> >
> >> haystack.contains(it, .ignoreCase=true)
> >
> >
> > ... is just beyond our ability to add to the language? Personally I
> think it's feasible, but it remains to be seen whether we're willing to do
> it without an explicit opt-in. A lot of people here think we need one.
>
> I think we can add mandatory-named parameters and optionally-named
> parameters into C++. I don't think we should waste our time trying to
> do either
> without declaration-level opt-in, as that will trigger OMDB opposition.
>


Who, specifically, has OMDB opposition to this, and what, specifically, is
their rationale for such opposition? Requiring mandatory opt-in for named
arguments is a significant adoption burden, it would seriously hamper the
usability of this feature. It’s one thing to expect me to change my code,
but obviously I can’t change somebody else’s — which makes the feature
theoretically attractive but practically borderline useless.

Parameter names are already some of the least likely things to change in a
function — since what we’re talking about is *solely* the potential cost to
a library author of changing a parameter name. Not the function name, not
the function behavior, just the parameter name in a vacuum. Is this
something that happens especially frequently that is a freedom that is
highly important to maintain?

Users can already depend on parameter names today, using external tools.
clang-tidy has bugprone-argument-comment, for instance. This is basically a
way of getting a limited form of named arguments today and allows me to
write `f(/*enable=*/true)`. Such code will break if `f` renames its
parameter to something other than `enable`. So?

This is even less of an issue for the standard library than other
libraries. Both because we will simply specify that all of the function
parameters are unspecified (until we choose to specify them) and also
because the parameter names are all sufficiently ugly that that is already
its own deterrent to avoid depending on them.

We do certainly need a mechanism for declaring a parameter positional-only
(you can call that an opt-out if you’d like), and we should seriously
consider a mechanism to declare a parameter keyword-only. But mandating an
opt-in is basically giving us named arguments in name only.

Barry

>