Sorry, typing on my phone and of course don't see the typos until after
hitting send. Fixed below...

On Sun, 4 Jan 2026, 20:45 Jonathan Wakely, <cxx_at_[hidden]> wrote:

>
>
> On Sun, 4 Jan 2026, 15:28 Jan Schultke via Std-Proposals, <
> std-proposals_at_[hidden]> wrote:
>
>> Leading by calling it "evil" is an extremely poor start to an argument.
>>> You have already convinced all skeptics that your argument lacks any
>>> substance.
>>
>>
>> What's the substance of *your* argument?
>>
>
> It seemed pretty clear to me that Barry's point was that parameter names
> were not part of the intended API for any existing library code, and
> changing that now by making those names significant (against the original
> authors' wishes of at least without their knowledge or
>

or at least without...

agreement) might be bad, or could be at least surprising.
>
>
>
>> You just assert that parameter names will "probably" require an explicit
>> opt-in without discussing the cost to the user of this choice. Then you
>> nitpick that I've used the word "evil", totally ignore any technical
>> argument I've made, and declare victory.
>>
>
> Your argument seemed to be "some other things are observable, so it
> doesn't make sense to say that parameter names must not be observable",
> which isn't really a relevant response to Barry's point.
>
> The things you identify as having been observable for 30 years have indeed
> been observable 30 years, and that's the point. That some things are
> already observable is not an argument for or against *changing* whether
> parameter names are observable. Nobody is claiming that it doesn't make
> sense for those names to be significant in an ideal world, only that we
> have existing code and constraints they
>

constraints that...

mean we don't have an ideal world.
>
>
>
>
>> On Sun, 4 Jan 2026 at 16:22, Barry Revzin <barry.revzin_at_[hidden]> wrote:
>>
>>>
>>>
>>> On Sun, Jan 4, 2026 at 9:15 AM Jan Schultke via Std-Proposals <
>>> std-proposals_at_[hidden]> wrote:
>>>
>>>> I think the evil of needing the explicit opt-in significantly outweighs
>>>> the perceived freedom it gives library authors.
>>>>
>>>
>>> Leading by calling it "evil" is an extremely poor start to an argument.
>>> You have already convinced all skeptics that your argument lacks any
>>> substance.
>>>
>>>
>>>
>>>> Note that as I've already mentioned, there are numerous properties of
>>>> functions that the user can observe but which are likely implementation
>>>> details, such as:
>>>>
>>>> - recursive leakage through headers
>>>> - expression validity tests / SFINAE stability
>>>> - ability to form function pointers and function references
>>>> - ability to pass template arguments explicitly, especially
>>>> cv-qualified types
>>>> - any property only obtainable through reflection (such as
>>>> parameter names)
>>>> - lack or existence of default function arguments
>>>> - lack or existence of default template arguments
>>>> - distinct declaration vs using-declaration of an existing global
>>>> entity
>>>> - various type choices, like using iterators as pointers
>>>> - existence of a noexcept specification or lack thereof
>>>>
>>>> Sometimes these are stable, but very often it's not intended for users
>>>> to rely on them. This has been the status quo of the last 30 years, and
>>>> people talk about adding function parameter names to this list as if it was
>>>> obviously unacceptable, but it really isn't.
>>>>
>>>> On the other hand, the ability to rely on function parameter names is
>>>> not really a problem in practice in languages with support for named
>>>> arguments, like Kotlin. It's only conjectured to be a major problem in C++.
>>>> However, an explicit opt-in would require every library author to do
>>>> significant work to permit passing named function arguments, and this work
>>>> isn't exactly clean and easy. Except for fresh C++29-only codebases, this
>>>> would devolve into code looking like:
>>>>
>>>> f(int x, int y);
>>>> f(
>>>> int MY_LIB_NAMED_SINCE_CXX29(x),
>>>> int MY_LIB_NAMED_SINCE_CXX29(x)
>>>> );
>>>>
>>>> I don't want to see every code base looking like this for the next
>>>> 10-20 years, or authors understandably not bothering with named parameters
>>>> because this looks disgusting. There could still be a per-function opt-in
>>>> rather than a per-parameter opt-in, but I'm not sure if that's worth the
>>>> trouble.
>>>>
>>>> On Sun, 4 Jan 2026 at 15:42, Sebastian Wittmeier via Std-Proposals <
>>>> std-proposals_at_[hidden]> wrote:
>>>>
>>>>> Parameter names are optional in function declarations. (And can be
>>>>> named differently from their counterpart in definitions.)
>>>>>
>>>>> So far they were either
>>>>>
>>>>> - kept the same between declaration and definition -> leak of
>>>>> internal (implementation) data
>>>>>
>>>>> - used as reminder for the programmer or for popups and autocompletes
>>>>> in IDEs; possibly also for compile error messages
>>>>>
>>>>>
>>>>>
>>>>> So the programmer already has a lot of flexibility. Nevertheless you
>>>>> are right, that the parameter names of included functions never leaked into
>>>>> the caller code up till now.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> -----Ursprüngliche Nachricht-----
>>>>> *Von:* Barry Revzin via Std-Proposals <std-proposals_at_[hidden]>
>>>>> *Gesendet:* So 04.01.2026 15:13
>>>>> *Betreff:* Re: [std-proposals] Labelled parameters
>>>>> *An:* std-proposals_at_[hidden];
>>>>> *CC:* Barry Revzin <barry.revzin_at_[hidden]>;
>>>>>
>>>>> Even when the parameter names are normal-ish, that's probably not
>>>>> something that library authors want users to rely on. For instance, in
>>>>> range-v3, the predicates and projections are pretty consistently named pred
>>>>> and proj, but is that the correct user-facing name? Eric and Casey have
>>>>> never had to think about this before. max(r, .proj=key) is definitely nicer
>>>>> to read than max(r, {}, key), but not as nice as max(r, .key=key) (or ".by"
>>>>> or something else). Lack of explicit opt-in cements a decision that up
>>>>> until now was never even a known decision.
>>>>>
>>>>> --
>>>>> Std-Proposals mailing list
>>>>> Std-Proposals_at_[hidden]
>>>>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>>>>
>>>> --
>>>> Std-Proposals mailing list
>>>> Std-Proposals_at_[hidden]
>>>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>>>
>>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>
>