[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.

[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