c++language-lawyercompiler-bugname-lookupdependent-name

Conditional operator's return type and two-phase lookup


Consider the following snippet:

struct Base { };
struct Derived : Base { };

void f(Base &) { std::cout << "f(Base&)\n"; }

template <class T = int>
void g() {
    Derived d;
    f(T{} ? d : d); // 1
}

void f(Derived &) { std::cout << "f(Derived&)\n"; }

int main() {
    g();
}

In this case, I reckon that the function call to f at // 1 should be looked up in phase one, since its argument's type is unambigously Derived&, and thus be resolved to f(Base&) which is the only one in scope.

Clang 3.8.0 agrees with me, but GCC 6.1.0 doesn't, and defers the lookup of f until phase two, where f(Derived&) is picked up.

Which compiler is right ?


Solution

  • Using the latest version of the C++ standard Currently n4582.

    In section 14.6 (p10) it says the name is bound at the point of declaration if the name is not dependent on a template parameter. If it depends on a template parameter this is defined in section 14.6.2.

    Section 14.6.2.2 goes on to say an expression is type dependent if any subexpression is type dependent.

    Now since the call to f() is dependent on its parameter. You look at the parameter type to see if it is depending on the type. The parameter is False<T>::value ? d : d. Here the first conditional is depending on the type T.

    Therefore we conclude that the call is bound at the point of instantiation not declaration. And therefore should bind to: void f(Derived &) { std::cout << "f(Derived&)\n"; }

    Thus g++ has the more accurate implementation.

    14.6 Name resolution [temp.res]

    Para 10:

    If a name does not depend on a template-parameter (as defined in 14.6.2), a declaration (or set of declarations) for that name shall be in scope at the point where the name appears in the template definition; the name is bound to the declaration (or declarations) found at that point and this binding is not affected by declarations that are visible at the point of instantiation.

    14.6.2.2 Type-dependent expressions [temp.dep.expr]

    Except as described below, an expression is type-dependent if any subexpression is type-dependent.