Movatterモバイル変換

[Moved to DR at the September, 2013 meeting.]

Proposed resolution, April, 2013:

1. Change 12.2.4.2.6 [over.ics.list] paragraph 2 asfollows, adding a new paragraph (and moving the footnote to the newparagraph, as indicated):

If the parameter typeisstd::initializer_list<X>or“array of X” [Footnote: Since there areno parameters of array type, this will only occur as theunderlying type of a reference parameter. —endfootnote] and all the elements of the initializerlist can be implicitly converted toX, the implicitconversion sequence is the worst conversion necessary toconvert an element of the list toX. Thisconversion can be a user-defined conversion even in thecontext of a call to an initializer-listconstructor. [Example: ... —endexample]

Otherwise, if the parameter type is “arrayofNX” [Footnote: Sincethere are no parameters of array type, this will only occuras the underlying type of a referenceparameter. —end footnote], if the initializerlist has exactlyN elements or if it has fewer thanNelements andX is default-constructible, and if all theelements of the initializer list can be implicitly convertedtoX, the implicit conversion sequence is the worstconversion necessary to convert an element of the list toX.

[Drafting note: no other case in the remainder of the paragraphapplies when the initializer list has more elements than the parameterarray.]

2. Change 12.2.4.3 [over.ics.rank] paragraph 3 as follows:

Two implicit conversion sequences of the same form areindistinguishable conversion sequences unless one of thefollowing rules applies:

• ...

• List-initialization sequenceL1 is a betterconversion sequence than list-initializationsequenceL2 ifL1 convertstostd::initializer_list<X> forsomeX andL2 does not.

• L1 converts tostd::initializer_list<X> for someX andL2 does not, or, if not that,

• L1 converts to type “arrayofN1T,”L2 converts totype “array ofN2T”,andN1 is smaller thanN2.

Notes from the October, 2012 meeting:

CWG determined that this issue is unrelated to array temporariesand that a tiebreaker should be added for this case in overloadresolution.

Rationale (August, 2011):

The implications of array temporaries for the language should beconsidered by the Evolution Working Group in a comprehensive fashionrather than on a case-by-case basis. See also issues1300,1326,and1525.

In an example like

  void f(int const(&)[2]);  void f(int const(&)[3]);  int main() {   f({1, 2, 3});  }

the current overload resolution rules make no provision for differentarray sizes and thus treats the call as ambiguous, even though it seemsobvious that the secondf should be chosen in this case.