IMHO Reflection is a bad comparison to named parameters.   Reflection is kind of a lower level facility. How often would a parameter name be hardcoded with reflection?   I could see it for giving certain names meaning.   foo(int alwayscalled0, int alwayscalled1);   code reflection could call   foo(0, 1)   after reading the names. [or something similar, e.g. used for auto-generated wrappers]   One would better use attributes in this case.     But it is more something I would expect from internal code from an organization than done to external libraries.   And if it is used with a library, then in glue code (wrappers) and not in normal application code.       -----Ursprüngliche Nachricht----- Von:Jason McKesson via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Di 06.01.2026 00:09 Betreff:Re: [std-proposals] Labelled parameters An:std-proposals_at_[hidden]; CC:Jason McKesson <jmckesson_at_[hidden]>; 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? 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? Is it even legal for a C++ standard library implementation to use the standard-defined parameter names? My understanding is that a lot of them use `_Capital` names 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. Because if standard library implementations cannot even keep a set of parameter names consistent across each other (despite it being documented), for all functions everywhere, then it seems silly to suggest that this can be done across the greater C++ ecosystem. -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals