Date: Mon, 5 Jan 2026 18:01:04 +0100
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. 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.
> 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?
How widespread is this particular tool use? I hadn't heard of this
particular check before.
> 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.
Sure, for the standard library, that's pretty easy,
but what about the rest of the code out there?
Jens
>
>
> 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. 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.
> 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?
How widespread is this particular tool use? I hadn't heard of this
particular check before.
> 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.
Sure, for the standard library, that's pretty easy,
but what about the rest of the code out there?
Jens
Received on 2026-01-05 17:01:11