I have the same thought. I have experienced named parameters in Python. you could just refer the parameter name to call the overload methods, which needs a map to locate the target method.

But I think this could be harmful to c++.
Below are my opinions:
  if we use named parameters, we don't need method overload anymore. And there's a question: if tow functions or methods has the same name with different type, are they overloaded?

Python is a bad language for design.

I code with cpp, just because I love the clear type differences, and templates, the most important is operator overload.

获取Outlook for Android<https://aka.ms/AAb9ysg>
________________________________
From: Std-Proposals <std-proposals-bounces_at_lists.isocpp.org> on behalf of Robin Savonen Söderholm via Std-Proposals <std-proposals_at_[hidden]>
Sent: Monday, January 5, 2026 3:49:46 PM
To: C++ Proposals <std-proposals_at_[hidden]>
Cc: Robin Savonen Söderholm <robinsavonensoderholm_at_[hidden]>
Subject: Re: [std-proposals] Labelled parameters

I think the overload resolution is a bigger issue than you make it sound. How does it interplay with type deductions, constraints priorities, ADL etc. when overloaded signatures exists?
Personally, I am starting to wonder if a named argument function needs to be something different from regular functions, one that does not allow redeclarations (or at least requires all declarations+definition to have the same argument names). Like:
```C++
// position only
void foo(int bar);
// named only
void /*named arguments tag for function*/ foo(int bar) { foo(bar); }
// alternative idea: automatic 'namify function'
void /*named arguments tag for function"/ foo(int bar) = default;
```
But this idea would sorta require that you can't mix positional and named arguments.

Anyway, I think that the overload management may be a bit of a problem on the technical side.

Another thing that I wonder is; how does it play with code quality and how does it compare with e.g. strong types? Is it risk that the threshold for refactoring in codebases gets higher and we see more "very many arguments signatures" out in the wild, something that often but not necessarily always is a code smell?

With strong types, you could do something like:
```C++
template <typename In, typename Out>
void copy_n(In in, std::size_t n, out<Out> out)...

void foo(...) {
  ..
  copy_n(begin(my_source), n, out(begin(dest)));
  ..
}
```

Now, I don't expect strong types to be part of STL (although it could be good), but it solves the problem in OP. (To be clear, I am not trying to "bring down" the proposal, but rather open the discussions for alternatives)

Hope you feel that I gave you something useful!
Have a good day

// Robin



On Mon, Jan 5, 2026, 08:03 Simon Schröder via Std-Proposals <std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>> wrote:
If this feature is not opt-in, maybe we should make it opt-out. Maybe some library writers don’t want to give guarantees for parameter names as part of their API. Without an explicit opt-out they’d have to declare all functions twice and change up parameter names in the second declaration. This does not seem like a convenient solution. (But it will happen if we don’t give a way for explicit control.)

I do see one problem with named parameters that other languages might not have: How is the interplay with overload resolution? This goes back to the point where a library author does not think about parameter names being part of their API, but someone will rely on it anyways. The library author might change parameter names and overload resolution might change because of this. (Maybe we can call this bad library design for cases where this can occur: parameter names should be consistent between overloads. So, either parameter names of all overloads are changed and the code using named parameters no longer compiler (which I think is fine) or a new overload is added and uses consistent parameter names (so the change has the same effect as right now without parameter names).)

On Jan 4, 2026, at 9:48 PM, Jonathan Wakely via Std-Proposals <std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>> wrote:


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_kayari.org<mailto:cxx_at_[hidden]>> wrote:


On Sun, 4 Jan 2026, 15:28 Jan Schultke via Std-Proposals, <std-proposals_at_[hidden]<mailto: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]<mailto:barry.revzin_at_[hidden]>> wrote:


On Sun, Jan 4, 2026 at 9:15 AM Jan Schultke via Std-Proposals <std-proposals_at_[hidden]<mailto: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]<mailto: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]<mailto:std-proposals_at_[hidden]>>
Gesendet: So 04.01.2026 15:13
Betreff: Re: [std-proposals] Labelled parameters
An: std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>;
CC: Barry Revzin <barry.revzin_at_[hidden]<mailto: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]<mailto:Std-Proposals_at_[hidden]>
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
--
Std-Proposals mailing list
Std-Proposals_at_[hidden]<mailto:Std-Proposals_at_[hidden]>
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
--
Std-Proposals mailing list
Std-Proposals_at_[hidden]<mailto:Std-Proposals_at_[hidden]>
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
--
Std-Proposals mailing list
Std-Proposals_at_lists.isocpp.org<mailto:Std-Proposals_at_[hidden]>
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
--
Std-Proposals mailing list
Std-Proposals_at_[hidden]ocpp.org<mailto:Std-Proposals_at_[hidden]>
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals