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
>