Movatterモバイル変換

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

Proposed resolution (August, 2011):

1. Change 12.2.2.7 [over.match.ref] paragraph 1 as follows:

• The conversion functions ofS and its base classesare considered, except that for copy-initialization, only thenon-explicit conversion functions are considered. Those that are nothidden withinS and yield type “lvalue reference tocv2T2” (when9.5.4 [dcl.init.ref]requires an lvalue resultinitializing an lvalue referenceor an rvalue reference to function) or “cv2T2” or “rvalue reference tocv2T2” (when9.5.4 [dcl.init.ref] requires anrvalue resultinitializing an rvalue reference or an lvaluereference to function), where “cv1T” is reference-compatible (9.5.4 [dcl.init.ref])with “cv2T2”, are candidatefunctions.

2. Change 12.2.4 [over.match.best] paragraph 1 as follows:

• ...

• the context is an initialization by user-defined conversion... orif not that,

• the context is an initialization by conversion functionfor direct reference binding (12.2.2.7 [over.match.ref]) of areference to function type, the return type ofF1 is the samekind of reference (i.e. lvalue or rvalue) as the reference beinginitialized, and the return type ofF2 is not[Example:

    template <class T> struct A {    operator T&();  // #1    operator T&&(); // #2  };  typedef int Fn();  A<Fn> a;  Fn& lf = a;      // calls #1  Fn&& rf = a;     // calls #2

  —end example] or, if not that,

• F1 is a non-template function...

According to 12.2.2.7 [over.match.ref] paragraph 1, thedetermination of the candidate functions is based on whether9.5.4 [dcl.init.ref] requires an lvalue result or an rvalueresult. It is not sufficiently clear exactly what this means,particularly with respect to function lvalues and rvalues.