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
[Moved to DR at the October, 2012 meeting.]
In 12.2.2.6 [over.match.conv], dealing with non-reference initialization, direct initialization considers as candidate functions only those that
yield type T or a type that can be converted to type T with a qualification conversion
By contrast, 12.2.2.7 [over.match.ref], dealing with reference binding, requires only that the type returned be reference-compatible with the target, permitting both qualification conversions and derived-to-base conversions. This discrepancy is presumably unintentional.
Proposed resolution (February, 2012):
Change 12.2.2.7 [over.match.ref] paragraph 1 as follows:
...the candidate functions are selected as follows:
The conversion functions of S and its base classes
are considered, except that for copy-initialization, only the
non-explicit conversion functions are considered. Those
non-explicit conversion functions that are not hidden
within S and yield type “lvalue reference to
cv2 T2” (when 9.4.4 [dcl.init.ref]
requires an lvalue result) or “cv2 T2” or
“rvalue reference to cv2 T2” (when
9.4.4 [dcl.init.ref] requires an rvalue result), where
“cv1 T” is reference-compatible
(9.4.4 [dcl.init.ref]) with “cv2
T2”, are candidate functions. For
direct-initialization, those explicit conversion functions that are not
hidden within S and yield type “lvalue reference to
cv2 T2,” or “cv2 T2” or
“rvalue reference to cv2 T2,”
respectively, where T2 is the same type as T or can
be converted to type T with a qualification conversion
(7.3.6 [conv.qual]), are also candidate
functions.