On Mon, 5 Jan 2026, 17:01 Jens Maurer via Std-Proposals, <
std-proposals_at_[hidden]> wrote:

>
>
> On 1/5/26 16:49, Barry Revzin via Std-Proposals wrote:
> >
> >
> > On Mon, Jan 5, 2026, 9:13 AM Ville Voutilainen via Std-Proposals <
> std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]>>
> wrote:
> >
> > On Mon, 5 Jan 2026 at 16:39, Jan Schultke via Std-Proposals
> > <std-proposals_at_[hidden] <mailto:
> 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?
>
> If we add named parameters to the C++xy feature set without the opt-in,
> the existing parameter names of all (non-std) libraries out there will
> become part of that library's API once some caller decides to use the
> named parameters feature. Hyrum's law says that's a given.
>
> If a library, having seen the new feature, now decides to actually
> rename their parameters (because the API should be nice, and their
> existing parameter names weren't bad enough to bother until now),
> they can't.



Hyrum's law says people will rely on it, but that doesn't mean you can't
change it. It just means people who used it wrong might have to fix their
bad code.




Put differently: parameter names are now _more_ likely
> to want to change in order to streamline your API.
>
> We can certainly decide that this concern is outweighed by globally
> available named parameters for existing libraries (and we all know
> extra syntax is often a curse), but we should at least acknowledge
> that scenario.
>

Agreed.