>
> 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?

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.

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