This is an unofficial snapshot of the ISO/IEC JTC1 SC22 WG21 Core Issues List revision 115d. See http://www.open-std.org/jtc1/sc22/wg21/ for the official list.
2024-10-26
[Adopted at the June, 2016 meeting.]
The resolution of issue 1467 made some plausible constructs ill-formed. For example,
struct A { A(int); }; struct B { B(A); }; B b{{0}};
This is now ambiguous, because the text disallowing user-defined conversions for B's copy and move constructors was removed from 12.2.4.2 [over.best.ics] paragraph 4. Another example:
struct Params { int a; int b; }; class Foo { public: Foo(Params); }; Foo foo{{1, 2}};
This is now ambiguous between Foo(Params) and Foo(Foo&&).
For non-class types, we allow initialization from a single-item list to perform a copy only if the element within the list is not itself a list (12.2.4.2.6 [over.ics.list] bullet 9.1). The analogous rule for this case would be to add back the bullet in 12.2.4.2 [over.best.ics] paragraph 4, but only in the case where the initializer is itself an initializer list:
the second phase of 12.2.2.8 [over.match.list] when the initializer list has exactly one element that is itself an initializer list, where the target is the first parameter of a constructor of class X, and the conversion is to X or reference to (possibly cv-qualified) X,
Proposed resolution (March, 2016):
Change 12.2.4.2 [over.best.ics] paragraph 4 as follows:
...and the constructor or user-defined conversion function is a candidate by
12.2.2.4 [over.match.ctor], when the argument is the temporary in the second step of a class copy-initialization,
or12.2.2.5 [over.match.copy], 12.2.2.6 [over.match.conv], or 12.2.2.7 [over.match.ref] (in all cases), or
the second phase of 12.2.2.8 [over.match.list] when the initializer list has exactly one element that is itself an initializer list, and the target is the first parameter of a constructor of class X, and the conversion is to X or reference to (possibly cv-qualified) X,
user-defined conversion sequences are not considered. [Note:...