Date: Mon, 05 Jan 2026 14:39:27 -0300
On Monday, 5 January 2026 14:01:04 Brasilia Standard Time Jens Maurer via Std-
Proposals wrote:
> 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.
Agreed, but not at the beginning. It should suffice to document what is
guaranteed to be kept stable and what is not, at least in the beginning. There
are also lots of available but private-ish API in ancillary namespaces and
such in public headers that one could call but shouldn't.
The feature will be announced and added to the standard much earlier than
people can begin using them. There should be enough time for maintained
libraries to adapt and adopt the feature.
The problem is long-term, for libraries that didn't bother. At some point, if
this is opt-out, you're right that users will begin using them because the
majority of libraries have adopted them and stop looking for the documentation
saying they have.
Plus the C libraries, including the Standard C Library itself. We probably
need to consult with WG14 on this. Even if they decide they don't want/need
the feature, we need to provide a syntax that is acceptable for C libraries to
use as an extension, especially if we decide to provide labeled parameters for
functions imported from the C library into the std:: namespace (e.g., memcpy).
But we should strive to convince them to adopt the full feature with the same
syntax, where it is applicable to C, because we in C++ want to use C libraries
with the feature.
Proposals wrote:
> 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.
Agreed, but not at the beginning. It should suffice to document what is
guaranteed to be kept stable and what is not, at least in the beginning. There
are also lots of available but private-ish API in ancillary namespaces and
such in public headers that one could call but shouldn't.
The feature will be announced and added to the standard much earlier than
people can begin using them. There should be enough time for maintained
libraries to adapt and adopt the feature.
The problem is long-term, for libraries that didn't bother. At some point, if
this is opt-out, you're right that users will begin using them because the
majority of libraries have adopted them and stop looking for the documentation
saying they have.
Plus the C libraries, including the Standard C Library itself. We probably
need to consult with WG14 on this. Even if they decide they don't want/need
the feature, we need to provide a syntax that is acceptable for C libraries to
use as an extension, especially if we decide to provide labeled parameters for
functions imported from the C library into the std:: namespace (e.g., memcpy).
But we should strive to convince them to adopt the full feature with the same
syntax, where it is applicable to C, because we in C++ want to use C libraries
with the feature.
-- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Principal Engineer - Intel Data Center - Platform & Sys. Eng.
Received on 2026-01-05 17:39:44
