Date: Sat, 10 Jan 2026 19:34:43 -0500
On 1/5/26 4:34 PM, Barry Revzin via Std-Proposals 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.
>
> I use plenty of libraries (open source included) that cause some code
> breakage in every release, some seemingly completely gratuitous. I
> just don't see this particular kind of breakage as being so
> exquisitely bad that it must not be allowed. In contrast to the value
> add of plenty of library APIs that already exist in the while with
> good (or good enough) names, since... you know... the code is
> self-documenting.
I agree that such code breakage tends to be easy to deal with as part of
upgrading a dependency. Let's consider another scenario however.
Many open source libraries have dependencies, but do not require a
particular version of each of their dependencies; they just have minimum
version requirements. Consider libraries with dependencies like zlib or
openssl. It is common for open source projects to expect to work with
whichever version of these projects is available on a system. As a
maintainer of an open source library that only specifies minimum
versions for dependent projects, what do you do if you discover that
your project no longer builds with a new version of a dependency because
a parameter name changed? Do you #ifdef the code based on the version of
the dependency used at build time? Do you bump the minimum version
requirements to the most recent version? I think I would quickly stop
using named arguments, at least in projects that don't have full control
over their dependencies.
From an ecosystem perspective, parameters used for named arguments need
to be stable.
Tom.
>
> [Jens]
>
> Sure, for the standard library, that's pretty easy,
> but what about the rest of the code out there?
>
>
> Other libraries can have documentation too. And if a library doesn't
> bother with documentation, I'm not sure what they would expect?
>
> [Thiago]
>
> Indeed, especially those with crappy APIs that fall into The
> Boolean Trap
> because they don't have overloads and member functions.
>
> This feature needs to be adoptable by C, even if at the end WG14
> decides not
> to adopt it. We should then gently pressure the C compiler people
> to provide
> it as an extension in C, so the C library authors can themselves
> opt in even
> if the standard language doesn't.
>
>
> I think being able to use C libraries is a good argument for simply
> allowing using existing names too.
>
> Barry
>
>
> [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.
>
> I use plenty of libraries (open source included) that cause some code
> breakage in every release, some seemingly completely gratuitous. I
> just don't see this particular kind of breakage as being so
> exquisitely bad that it must not be allowed. In contrast to the value
> add of plenty of library APIs that already exist in the while with
> good (or good enough) names, since... you know... the code is
> self-documenting.
I agree that such code breakage tends to be easy to deal with as part of
upgrading a dependency. Let's consider another scenario however.
Many open source libraries have dependencies, but do not require a
particular version of each of their dependencies; they just have minimum
version requirements. Consider libraries with dependencies like zlib or
openssl. It is common for open source projects to expect to work with
whichever version of these projects is available on a system. As a
maintainer of an open source library that only specifies minimum
versions for dependent projects, what do you do if you discover that
your project no longer builds with a new version of a dependency because
a parameter name changed? Do you #ifdef the code based on the version of
the dependency used at build time? Do you bump the minimum version
requirements to the most recent version? I think I would quickly stop
using named arguments, at least in projects that don't have full control
over their dependencies.
From an ecosystem perspective, parameters used for named arguments need
to be stable.
Tom.
>
> [Jens]
>
> Sure, for the standard library, that's pretty easy,
> but what about the rest of the code out there?
>
>
> Other libraries can have documentation too. And if a library doesn't
> bother with documentation, I'm not sure what they would expect?
>
> [Thiago]
>
> Indeed, especially those with crappy APIs that fall into The
> Boolean Trap
> because they don't have overloads and member functions.
>
> This feature needs to be adoptable by C, even if at the end WG14
> decides not
> to adopt it. We should then gently pressure the C compiler people
> to provide
> it as an extension in C, so the C library authors can themselves
> opt in even
> if the standard language doesn't.
>
>
> I think being able to use C libraries is a good argument for simply
> allowing using existing names too.
>
> Barry
>
Received on 2026-01-11 00:34:50