operator[] lookup into template base classes

Question

The following code is causing a little headache for us: clang and MSVC accepts the following code, while GCC rejects it. We believe GCC is right this time, but I wanted to make it sure before filing the bugreports. So, are there any special rules for operator[] lookup that I'm unaware of?

struct X{};
struct Y{};

template<typename T>
struct B
{
    void f(X) { }
    void operator[](X){}
};

template<typename T>
struct C
{
    void f(Y) { }
    void operator[](Y){}
};

template<typename T> struct D : B<T>, C<T> {};

int main()
{
    D<float> d;
    //d.f(X()); //This is erroneous in all compilers
    d[Y()];//this is accepted by clang and MSVC
}

So is the above code is correct in resolving the operator[] call in the main function?

Answer 1

It's not 100% clear in which compiler the issue lie. The standard goes over a lot of rules for name lookup (which is what this is an issue with), but more specifically section 13.5.5 covers the operator[] overload:

13.5.5 Subscripting [over.sub]

1 - operator[] shall be a non-static member function with exactly one parameter. It implements the subscripting syntax

postfix-expression [ expr-or-braced-init-list ]

Thus, a subscripting expression x[y] is interpreted as x.operator[](y) for a class object x of type T if T::operator[](T1) exists and if the operator is selected as the best match function by the overload resolution mechanism (13.3.3).

Looking at the standard on Overloading (chapter 13):

13 Overloading [over]

1 - When two or more different declarations are specified for a single name in the same scope, that name is said to be overloaded. By extension, two declarations in the same scope that declare the same name but with different types are called overloaded declarations. Only function and function template declarations can be overloaded; variable and type declarations cannot be overloaded.

2 - When an overloaded function name is used in a call, which overloaded function declaration is being referenced is determined by comparing the types of the arguments at the point of use with the types of the parameters in the overloaded declarations that are visible at the point of use. This function selection process is called overload resolution and is defined in 13.3.

...

13.2 Declaration matching [over.dcl]

1 - Two function declarations of the same name refer to the same function if they are in the same scope and have equivalent parameter declarations (13.1). A function member of a derived class is not in the same scope as a function member of the same name in a base class.

So according to this and section 10.2 on derived classes, since you've declared struct D : B, C, both B and C have member functions for operator[] but different types, thus the operator[] function is overloaded within the scope of D (since there's no using nor is operator[] overridden or hidden directly in D).

Based on this, MSVC and Clang are incorrect in their implementations since d[Y()] should be evaluated to d.operator[](Y()), which would produce an ambiguous name resolution; so the question is why do they accept the syntax of d[Y()] at all?

The only other areas I could see with regards to the subscript ([]) syntax make reference to section 5.2.1 (which states what a subscript expression is) and 13.5.5 (stated above), which means that those compilers are using other rules to further compile the d[Y()] expression.

If we look at name lookup, we see that 3.4.1 Unqualified name lookup paragraph 3 states that

The lookup for an unqualified name used as the postfix-expression of a function call is described in 3.4.2.

Where 3.4.2 states:

3.4.2 Argument-dependent name lookup [basic.lookup.argdep]

1 - When the postfix-expression in a function call (5.2.2) is an unqualified-id, other namespaces not considered during the usual unqualified lookup (3.4.1) may be searched, and in those namespaces, namespace-scope friend function or function template declarations (11.3) not otherwise visible may be found.

2 - For each argument type T in the function call, there is a set of zero or more associated namespaces and a set of zero or more associated classes to be considered. The sets of namespaces and classes is determined entirely by the types of the function arguments (and the namespace of any template template argument). Typedef names and using-declarations used to specify the types do not contribute to this set. The sets of namespaces and classes are determined in the following way:

...

(2.2) - If T is a class type (including unions), its associated classes are: the class itself; the class of which it is a member, if any; and its direct and indirect base classes. Its associated namespaces are the innermost enclosing namespaces of its associated classes. Furthermore, if T is a class template specialization, its associated namespaces and classes also include: the namespaces and classes associated with the types of the template arguments provided for template type parameters (excluding template template parameters); the namespaces of which any template template arguments are members; and the classes of which any member templates used as template template arguments are members. [ Note: Non-type template arguments do not contribute to the set of associated namespaces.—end note ]

Note the emphasis on may.

With the above points and a couple of others from 3.4 (name lookup), one could believe that Clang and MSVC are using these rules to find d[] first (and thus finding it as C::operator[]) vs. using 13.5.5 to turn d[] into d.operator[] and continuing compilation.

It should be noted that bringing the operators of the base classes into scope of the D class or using explicit scope does, however, 'fix' this issue across all three compilers (as is expected based on the using declaration clauses in the references), example:

struct X{};
struct Y{};

template<typename T>
struct B
{
    void f(X) { }
    void operator[](X) {}
};

template<typename T>
struct C
{
    void f(Y) { }
    void operator[](Y) {}
};

template<typename T>
struct D : B<T>, C<T>
{
    using B<T>::operator[];
    using C<T>::operator[];
};

int main()
{
    D<float> d;

    d.B<float>::operator[](X()); // OK
    //d.B<float>::operator[](Y()); // Error

    //d.C<float>::operator[](X()); // Error
    d.C<float>::operator[](Y()); // OK

    d[Y()]; // calls C<T>::operator[](Y)
    return 0;
}

Since the standard is ultimately left to the interpretation of the implementer, I'm not sure which compiler would be technically correct in this instance since MSVC and Clang might be using other rules to compile this though, given the subscripting paragraphs from the standard, I'm inclined to say they are not strictly adhering to the standard as much as GCC is in this instance.

I hope this can add some insight into the problem.