Talk:cpp/language/overload resolution

wrong code snippet in 'Ranking of implicit conversion sequences' section

struct Base {};
struct Derived : Base {} b;
int f(A&); // overload #1
int f(B&); // overload #2
int i = f(b); // b -> B& has rank Exact Match
              // b -> A& has rank Conversion
              // calls f(B&)

What are A and B types used in function arguments ??? --92.255.187.52 06:32, 18 October 2013 (PDT)

Good catch, fixed. --Cubbi (talk) 07:02, 18 October 2013 (PDT)

Wrong example with list initialization vs non-list initialization

The example for "A list-initialization sequence L1 is better than list-initialization sequence L2 if L1 initializes an std::initializer_list parameter, while L2 does not" is wrong. A right example would be

  void f(int);
  void f(std::initializer_list<int>);

  // call
  f({42});

The example with vector uses two-phase overload resolution on constructors, and in the first phase only initializer list constructors are considered. This is the mechanism by which the vector example is "disambiguated".

litb 91.2.84.210 16:05, 6 November 2014 (PST)

you're right, litb, I made the change. --Cubbi (talk) 16:51, 6 November 2014 (PST)

Parameter and Argument are confusing terms

> ...the candidate function whose parameters match the arguments most closely is the one that is called

> If there are M arguments, the candidate function that has exactly M parameters is viable

These two sentences imply that Parameter is the term used as in 'formal parameter', while Argument is the 'actual parameter'.

On the other hand,

> ...the implicit conversion sequences from the i-th parameter to i-th argument...

implies the opposite.

I suggest to use the 'formal' and 'actual' adjectives throughout this article to avoid confusion, or else at least define these two terms unambiguously at the top of the page, and apply this definition consistently.

That would mean we'd have to introduce and explain the terms "formal parameter" and "actual parameter", which do not appear in the C++ standard. The C standard mentions them as long-obsolete aliases of "parameter" and "argument". The last quote is an error though (now fixed -- thanks: ICS is from argument to parameter. --Cubbi (talk) 08:44, 1 June 2017 (PDT)

"conversion is only possible if the parameter has an aggregate type that can be initialized from that initializer list according to the rules for aggregate initialization,"

There's a subtlety here that the spec explains by a note, but that's missing here. I think this should be outlined more clearly here, because on the article of "aggregate initialization", cppreference states that the designation shall be in member order. The note in the spec reads:

"[Note 1: Aggregate initialization does not require that the members are declared in designation order. If, after overload resolution, the order does not match for the selected overload, the initialization of the parameter will be ill-formed ([dcl.init.list]).]"

This was confusing me about the presentation on cppreference, because the first part of the note is missing here (by which it is not the aggregate initialization that's illformed, but the list initialization that's involved). 2003:EB:6F02:E800:1E69:7AFF:FE62:57E2 09:11, 16 January 2023 (PST)