On Mon, 5 Jan 2026 at 19:17, Ville Voutilainen
<ville.voutilainen_at_[hidden]> wrote:
>
> 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.

I should also add that I think I know how to do a form of
mandatory-named parameters that deliberately affects the function
type, the signature, and the name mangling - for decently good
reasons. It makes name-forwarding Just Work, and it makes things
so that a change in a parameter name is an ABI break, so that you
can't call the function with the wrong parameter names,
even in cases where definitions and declarations disagree due to
version mismatches.

I don't think I want that to happen automatically for whichever functions.

Yes, there are reasons to provide the ability to do named-arg calls
where the functions don't have those properties, too.
But even there, because of the other reasons, it seems quite
reasonable to have the declaration opt into being
callable-by-parameter-names.