Date: Mon, 5 Jan 2026 19:17:26 +0200
On Mon, 5 Jan 2026 at 19:01, Jens Maurer via Std-Proposals
<std-proposals_at_[hidden]> wrote:
> > 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.
There are also scenarios where forward-declarations are added or
modified or removed for various functions in header-only libraries,
with an arbitrary frequency, including for functions directly
available in the API.
Yes, such changes can already break reflective uses. But that's a
rather poor reason to add more breakable dependencies without
the library author asking for them.
<std-proposals_at_[hidden]> wrote:
> > 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.
There are also scenarios where forward-declarations are added or
modified or removed for various functions in header-only libraries,
with an arbitrary frequency, including for functions directly
available in the API.
Yes, such changes can already break reflective uses. But that's a
rather poor reason to add more breakable dependencies without
the library author asking for them.
Received on 2026-01-05 17:17:43