If it was opt-in, does that mean C libraries would never come with named
parameters enabled?
There's a lot of C functions I would love to use named parameters on.

I am assuming one could add redeclarations with the opt-in to enable.
Wondering how often code will break because of conflicting redeclarations.
(your libA depends on libB and libC, both of which depend on libD and
introduce redeclarations for named parameters)

If the mechanism was implicit / opt-out, I would have the following mindset:
If the library doesn't explicitly state they keep their parameter names
stable, I would be aware using them can break on upgrades, and avoid using
them without a really good reason
 - the good reason could be "I won't be upgrading that often, and I am fine
fixing up the compilation errors if they ever happen, and they improve my
ergonomics sufficiently"


On Mon, Jan 5, 2026 at 7:01 PM Sebastian Wittmeier via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> There are solutions for opt-in/opt-out.
>
> Create a transition-period:
>
> - First opt-in (C++29), later opt-out (C++32).
>
> or
>
> - first implementation-defined (e.g. compiler switch or #pragma) to avoid
> opt-in switch syntax, later opt-out
>
>
>
> The idea would be to give libraries some (light or experimental) exposure,
> they change their parameter names (or opt out) and only then they get full
> exposure.
>
>
> -----Ursprüngliche Nachricht-----
> *Von:* Jens Maurer via Std-Proposals <std-proposals_at_[hidden]>
> *Gesendet:* Mo 05.01.2026 18:01
> *Betreff:* Re: [std-proposals] Labelled parameters
> *An:* std-proposals_at_[hidden];
> *CC:* Jens Maurer <jens.maurer_at_[hidden]>;
>
>
> 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
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>