On Mon, 5 Jan 2026, 23:09 Jason McKesson via Std-Proposals, <
std-proposals_at_[hidden]> wrote:

> On Mon, Jan 5, 2026 at 4:34 PM Barry Revzin via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
> >
> >
> > [Jens]
> >
> >>>
> >>> 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.
> >
> >
> > [Wakely]
> >>
> >> 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.
> >
> >
> > Exactly. Hyrum's Law is simply an observation that observable behavior
> will be depended upon. It's not an obligation that all observable behavior
> be preserved in perpetuity. If a library, having seen the new feature,
> decides to actually rename their parameters, they certainly can choose to.
> It's just a choice for that library to make. Just like it's a choice for
> any other change they might want to make.
> >
> > Besides, with Reflection in C++26, an absolutely enormous amount of
> every library surface is now observable. But I don't think anyone would
> reasonably argue that no library anywhere can ever change again. And C++26
> Reflection even gives me the ability to write the world's least ergonomic
> named argument library (well, after strong types — nothing is less
> ergonomic than using strong types for named arguments), like
> call<^^ranges::max>(r, named<"__proj">(key)). But I don't really have a
> reasonable expectation that this would work in perpetuity, nor would a
> standard library implementor take my bug report very seriously if they
> renamed that parameter and I asked them to change it back. It's just
> another kind of change that can cause breakage.
>
> Here's a question: how many standard library implementations actually
> use the parameter names that the standard says those functions must
> have?



I can answer this one: none, because it's a trick question! The standard
doesn't say the functions must have those names, so no implementations can
use the required names, because there are no required names.


If every parameter name ever written is now baked into the API,
> as core a part of the API as the function name itself, then it *must*
> be the case that the C++ standard library follows suit, correct?
>

No, I don't see how that follows.



> Is it even legal for a C++ standard library implementation to use the
> standard-defined parameter names?


It depends on the name. Some parameter names happen to use names that are
already reserved by the standard library (e.g. "first" is reserved because
of std::pair::first so any parameter called first can be named exactly that
in an implementation).


My understanding is that a lot of
> them use `_Capital` names


Only one of the Majestic Three does that. The other two use __lower.


for parameters to provide protection against
> rogue macros. If they don't do that, then it's possible for
> implementations included via headers to be broken by macros defining
> parameter names.
>

Yes.


> Because if standard library implementations cannot even keep a set of
> parameter names consistent across each other (despite it being
> documented),


The names are not "documented" as being part of the API, because they're
not currently part of the API, and are not observable. Even with
reflection, the parameter names (and whether you can reflect standard
functions at all) are unspecified.


for all functions everywhere, then it seems silly to
> suggest that this can be done across the greater C++ ecosystem.
>

There are several claims in this mail that I don't think stand up to
scrutiny.