Date: Mon, 05 Jan 2026 20:19:23 +0000
On Monday, January 5th, 2026 at 7:50 AM, Barry Revzin via Std-Proposals <std-proposals_at_[hidden]> wrote:
> [...] It’s one thing to expect me to change my code, but obviously I can’t change somebody else’s — which makes the feature theoretically attractive but practically borderline useless.
Useless or not, that's perfect - thank you for
not using my parameter names without
permission. Let's not repeat Python 2's
sloppy design.
>
> Parameter names are already some of the least likely things to change in a function — since what we’re talking about is *solely* the potential cost to a library author of changing a parameter name. Not the function name, not the function behavior, just the parameter name in a vacuum. Is this something that happens especially frequently that is a freedom that is highly important to maintain?
They can change, sometimes purely for code
consistency. They can also split; one overload
becomes two, with the replacement parameter
named differently in both.
>
> Users can already depend on parameter names today, using external tools. clang-tidy has bugprone-argument-comment, for instance. This is basically a way of getting a limited form of named arguments today and allows me to write `f(/*enable=*/true)`. Such code will break if `f` renames its parameter to something other than `enable`. So?
So? They break because the library user wants
them to break. That is not the same as the feature
a library author wants to offer.
> This is even less of an issue for the standard library than other libraries. Both because we will simply specify that all of the function parameters are unspecified (until we choose to specify them) and also because the parameter names are all sufficiently ugly that that is already its own deterrent to avoid depending on them.
Then we are about to lie to the users everywhere,
because cppreference documented the parameter
names.
>
> We do certainly need a mechanism for declaring a parameter positional-only (you can call that an opt-out if you’d like), and we should seriously consider a mechanism to declare a parameter keyword-only. But mandating an opt-in is basically giving us named arguments in name only.
>
Oh, everybody claims that their feature
"won't gain adoption without being enabled
by default." Sometimes I just can't compose
the picture where one has such motivation
to write a paper with such low confidence
in the significance of the proposed feature.
> [...] It’s one thing to expect me to change my code, but obviously I can’t change somebody else’s — which makes the feature theoretically attractive but practically borderline useless.
Useless or not, that's perfect - thank you for
not using my parameter names without
permission. Let's not repeat Python 2's
sloppy design.
>
> Parameter names are already some of the least likely things to change in a function — since what we’re talking about is *solely* the potential cost to a library author of changing a parameter name. Not the function name, not the function behavior, just the parameter name in a vacuum. Is this something that happens especially frequently that is a freedom that is highly important to maintain?
They can change, sometimes purely for code
consistency. They can also split; one overload
becomes two, with the replacement parameter
named differently in both.
>
> Users can already depend on parameter names today, using external tools. clang-tidy has bugprone-argument-comment, for instance. This is basically a way of getting a limited form of named arguments today and allows me to write `f(/*enable=*/true)`. Such code will break if `f` renames its parameter to something other than `enable`. So?
So? They break because the library user wants
them to break. That is not the same as the feature
a library author wants to offer.
> This is even less of an issue for the standard library than other libraries. Both because we will simply specify that all of the function parameters are unspecified (until we choose to specify them) and also because the parameter names are all sufficiently ugly that that is already its own deterrent to avoid depending on them.
Then we are about to lie to the users everywhere,
because cppreference documented the parameter
names.
>
> We do certainly need a mechanism for declaring a parameter positional-only (you can call that an opt-out if you’d like), and we should seriously consider a mechanism to declare a parameter keyword-only. But mandating an opt-in is basically giving us named arguments in name only.
>
Oh, everybody claims that their feature
"won't gain adoption without being enabled
by default." Sometimes I just can't compose
the picture where one has such motivation
to write a paper with such low confidence
in the significance of the proposed feature.
-- Zhihao Yuan, ID lichray The best way to predict the future is to invent it. _______________________________________________
Received on 2026-01-05 20:19:34