Ambiguity with [] operator and multiple inheritance

Question

Consider the following class:

class Foo
{
    public:

    void operator [] (const std::string& s) { }

    void operator [] (std::size_t idx) { }
};

Here, given an instance of Foo f, the expression f[0] is not ambiguous, because the compiler chooses the second overload. Likewise, the expression f["abc"] is not ambiguous, because the compiler chooses the first overload (since a const char* is convertible to an std::string).

So, why is it then, that if we have two Base classes, each with a different overload, that there is suddenly ambiguity?

Suppose we have:

class Base1
{
    public:

    void operator [] (const std::string& s) { }
};

class Base2
{
    public:

    void operator [] (std::size_t idx) { }
};

class Derived : public Base1, public Base2
{ };

Now, if we say:

Derived d;
d[0];

The compiler complains:

    error: request for member ‘operator[]’ is ambiguous
      d[0];
         ^
   note: candidates are: void Base2::operator[](std::size_t)
      void operator [] (std::size_t idx) { }
           ^
   note:                 void Base1::operator[](const string&)
      void operator [] (const std::string& s) { }

Why does the fact that both operator overloads are now in Base classes cause any ambiguity? And is there some way to resolve this?

EDIT: Could this be a compiler bug (I am using GCC 4.8.1)

Answer 1

This is not an issue with overload resolution, but rather with member name lookup, which is defined in 10.2. Consider (as I'd rather not write operator[] everywhere):

struct base1 { void f(int); };
struct base2 { void f(double); };
struct derived : base1, base2 {};
int main() {
   derived d; d.f(0);
}

When lookup for f starts in the postfix expression d.f(0), it will first look into derived and find that f does not resolve to anything at all. 10.2/5 then requires that lookup proceeds to all base classes in parallel, constructing separate lookup sets. In this case, S(f,base1) = { base1::f } and S(f,base2) = { base2::f }. The sets are then merged following the rules in 10.2/6. The first bullet deals with merging when one of the sets is empty or if the lookup for the different sets ended with the same member (consider that it hit a common base). The second bullet is the interesting one, as it applies here

10.2/6 bullet 2

Otherwise, if the declaration sets of S(f,Bi) and S(f,C) differ, the merge is ambiguous: the new S(f,C) is a lookup set with an invalid declaration set and the union of the subobject sets. In subsequent merges, an invalid declaration set is considered different from any other.

That is, S(f,base1) differs from S(f,base2), so S(f,derived) becomes an invalid declaration set. And lookup fails.

Answer 2

The call is ambiguous because the two operators do not overload. Overloading applies only to names that are defined in the same scope. Base1 and Base2 define two different scopes, so in the derived class the compiler simply sees two identical names that have no connection. As the other answers have said, the way to overcome this is to hoist both names into the derived class with appropriate using declarations; when that is done, the compiler sees the two names in the scope of the definition of the derived class, and applies overload resolution.

Answer 3

class Derived : public Base1, public Base2
{ 
    public:
    using Base1::operator[];
    using Base2::operator[];
};

Make the inherits explicit, so there is no need for the compiler to 'select a base'.

Answer 4

TL;DR: Although both functions are in the candidate set, the candidate set is also invalid, making the program ill-formed. See dribeas's answer for details on that.

---

Both functions are clearly viable, since:

f((size_t)0)

and

f((const char*)0)

are legal and both conversion sequences are implicit.

Originally, the two candidates were not ambiguous because one was a better conversion than the other. The compiler chose the one that required only an integral promotion. Since an integral promotion was "better" than the other conversion sequence, it won.

Now, both candidates require a pointer upcast. Now the conversion sequence involving an upcast and integral promotion is no longer clearly better. So the compiler cannot choose and it reports ambiguity. (Note: I think the conversion sequence without user-defined conversion should still be better, and that candidate f(Base2* implicit, size_t) should still win... but it is MUCH more complicated now, because of the overload resolution rules involving conversions of multiple arguments.)

The "using" declaration allows the this pointer to be passed with an identity conversion instead of an upcast, so again one conversion sequence is just the integral promotion, which IS better.

---

From section 13.3.1:

The set of candidate functions can contain both member and non-member functions to be resolved against the same argument list. So that argument and parameter lists are comparable within this heterogeneous set, a member function is considered to have an extra parameter, called the implicit object parameter, which represents the object for which the member function has been called. For the purposes of overload resolution, both static and non-static member functions have an implicit object parameter, but constructors do not.

Similarly, when appropriate, the context can construct an argument list that contains an implied object argument to denote the object to be operated on. Since arguments and parameters are associated by position within their respective lists, the convention is that the implicit object parameter, if present, is always the first parameter and the implied object argument, if present, is always the first argument.

and

During overload resolution, the implied object argument is indistinguishable from other arguments. The implicit object parameter, however, retains its identity since conversions on the corresponding argument shall obey these additional rules:

• no temporary object can be introduced to hold the argument for the implicit object parameter; and

• no user-defined conversions can be applied to achieve a type match with it.

Answer 5

Have you tried explicitly saying that Derived exposes both?

class Derived : public Base1, public Base2
{
public:
    using Base1::operator[];
    using Base2::operator[];
};

I have no idea whether it may work, I only have Visual here.