Should this compile? Overload resolution and implicit conversions

Question

This example seems to compile with VC10 and gcc (though my version of gcc is very old).

EDIT: R. Martinho Fernandez tried this on gcc 4.7 and the behaviour is still the same.

struct Base
{
    operator double() const { return 0.0; }
};

struct foo
{
    foo(const char* c) {}
};

struct Something : public Base
{
    void operator[](const foo& f) {}
};

int main()
{
    Something d;
    d["32"];

    return 0;
}

But clang complains:

test4.cpp:19:6: error: use of overloaded operator '[]' is ambiguous (with operand types 'Something' and 'const char [3]')
    d["32"]
    ~^~~~~
test4.cpp:13:10: note: candidate function
    void operator[](const foo& f) {}
         ^
test4.cpp:19:6: note: built-in candidate operator[](long, const char *)
    d["32"]
     ^
test4.cpp:19:6: note: built-in candidate operator[](long, const restrict char *)
test4.cpp:19:6: note: built-in candidate operator[](long, const volatile char *)
test4.cpp:19:6: note: built-in candidate operator[](long, const volatile restrict char *)

The overload resolution is considering two possible functions from looking at this expression:

calling Something::operator[] (after a user defined conversion)
calling built in operator for const char* (think "32"[d]) (after a user defined conversion and standard conversion double to long).

If I had written d["32"] as d.operator[]("32"), then overload resolution won't even look at option 2, and clang will also compile fine.

EDIT: (clarification of questions)

This seems to be a complicated area in overload resolution, and because of that I'd appreciate very much answers that explain in detail the overload resolution in this case, and cite the standard (if there's some obscure/advanced likely to be unknown rule).

If clang is correct, I'm also interested in knowing why the two are ambiguous / one is not preferred over another. The answer likely would have to explain how overload resolution considers implicit conversions (both user defined and standard conversions) involved on the two candidates and why one is not better than the other.

Note: if operator double() is changed to operator bool(), all three (clang, vc, gcc) will refuse to compile with similar ambiguous error.

To clarify where the (possible) ambiguity comes from: `a[b]` is equivalent to `b[a]` when `operator[]` isn't overloaded. — Mike Seymour, Jan 18 '12 at 18:05
Right, I was about to add that minutes ago. Will do, thanks. — ryaner, Jan 18 '12 at 18:07
Since you mentioned your GCC is very old, I tried it on the yet to be released 4.7. It acts the same as yours: compile the original just fine, and error out with `operator bool`. — R. Martinho Fernandes, Jan 18 '12 at 18:08
Thanks for trying it out. Will make an edit to reflect your effort. — ryaner, Jan 18 '12 at 18:10
@MikeSeymour: `a[b]` is not equivalent to `b[a]` in this case (as `a` in this case is not `const char*` or convertible to it). What you are saying is this case : `char a[100]; int b;` then `a[b]` is equivalent to `b[a]`. — Nawaz, Jan 18 '12 at 18:12
@Nawaz: I'm not quite sure what you're saying; one of the arguments (call it `a` or `b` as you will, since they are symmetrical) *is* `const char *` in this case. — Mike Seymour, Jan 18 '12 at 18:27
@MikeSeymour: But the other argument *is not* `int`. So `a[b]` isn't equivalent to `b[a]`. — Nawaz, Jan 18 '12 at 18:30
@Nawaz: standard conversion will happily convert double to int OR bool to int. or in the case of clang probably to long.. as the error message implies. User defined conversion is allowed to be followed by standard conversion in overload resolution according to the C++ standard. (Someone correct me if I'm wrong). — ryaner, Jan 18 '12 at 18:30
@ryaner: That is what I'm thinking is the cause of the problem. — Nawaz, Jan 18 '12 at 18:32
@Nawaz: The other argument is convertible to an integer, so it *might be* equivalent. Whether it is or not, is the subject of this question; which I'm not answering because I don't know. I just thought it might be helpful to explain where the ambiguity would come from, if it exists. — Mike Seymour, Jan 18 '12 at 18:34
Using a `double` as an array subscript isn't allowed, and apparently converting to `int` isn't considered (clang and VC2010 reject `0.0["A"]`). So are those built-in candidates actually valid? If you change `Base::operator double()` to `operator int` then VC2010 rejects the code as ambiguous. — bames53, Jan 18 '12 at 19:08
@barnes53: it's likely that it's because in 0.0["A"] there's no user defined conversions involved whereas in my example there is. Here's a quote from the standard: "A user-defined conversion sequence consists of an initial standard conversion sequence followed by a userdefined conversion (12.3) followed by a second standard conversion sequence."(someone correct me if I'm wrong) — ryaner, Jan 18 '12 at 19:13
@ryaner there's no user defined sequence, but shouldn't it still be looking at valid candidates and comparing implicit conversion sequences? Anyway, I'm not sure what this means, but VC2011 IntelliSense seems to show the same error as clang, even if the actual compiler doesn't. — bames53, Jan 18 '12 at 19:22
@barnes53 you are right. That's an interesting find. I hope someone knows the answer. I'm curious as well. — ryaner, Jan 18 '12 at 19:31

score 12 · Accepted Answer · edited Jun 20 '20 at 09:12

It should be easier to picture why the overload resolution is ambiguous by going through it step-by-step.

§13.5.5 [over.sub]

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).

Now, we first need an overload set. That's constructed according to §13.3.1 and contains member aswell as non-member functions. See this answer of mine for a more detailed explanation.

§13.3.1 [over.match.funcs]

p2 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. [...]

p3 Similarly, when appropriate, the context can construct an argument list that contains an implied object argument to denote the object to be operated on.

// abstract overload set (return types omitted since irrelevant)
f1(Something&, foo const&); // linked to Something::operator[](foo const&)
f2(std::ptrdiff_t, char const*); // linked to operator[](std::ptrdiff_t, char const*)
f3(char const*, std::ptrdiff_t); // linked to operator[](char const*, std::ptrdiff_t)

Then, an argument list is constructed:

// abstract argument list
(Something&, char const[3]) // 'Something&' is the implied object argument

And then the argument list is tested against every member of the overload set:

f1 -> identity match on argument 1, conversion required for argument 2
f2 -> conversion required for argument 1, conversion required for argument 2 (decay)
f3 -> argument 1 incompatible, argument 2 incompatible, discarded

Then, since we found out that there are implicit conversions required, we take a look at §13.3.3 [over.match.best] p1:

Define ICSi(F) as follows:

if F is a static member function, [...]; otherwise,

let ICSi(F) denote the implicit conversion sequence that converts the i-th argument in the list to the type of the i-th parameter of viable function F. 13.3.3.1 defines the implicit conversion sequences and 13.3.3.2 defines what it means for one implicit conversion sequence to be a better conversion sequence or worse conversion sequence than another.

Now let's construct those implicit conversion sequences for f1 and f2 in the overload set (§13.3.3.1):

ICS1(f1): 'Something&' -> 'Someting&', standard conversion sequence
ICS2(f1): 'char const[3]' -> 'foo const&', user-defined conversion sequence
ICS1(f2): 'Something&' -> 'std::ptrdiff_t', user-defined conversion sequence
ICS2(f2): 'char const[3]' -> 'char const*', standard conversion sequence

§13.3.3.2 [over.ics.rank] p2

a standard conversion sequence (13.3.3.1.1) is a better conversion sequence than a user-defined conversion sequence or an ellipsis conversion sequence.

So ICS1(f1) is better than ICS1(f2) and ICS2(f1) is worse than ICS2(f2).
Conversely, ICS1(f2) is worse than ICS1(f1) and ICS2(f2) is better than ICS2(f1).

§13.3.3 [over.match.best]

p1 (cont.) Given these definitions, a viable function F1 is defined to be a better function than another viable function F2 if for all arguments i, ICSi(F1) is not a worse conversion sequence than ICSi(F2), and then [...]

p2 If there is exactly one viable function that is a better function than all other viable functions, then it is the one selected by overload resolution; otherwise the call is ill-formed.

Well, f*ck. :) As such, Clang is correct in rejecting that code.

Chris Dodd · Answer 2 · 2012-01-18T20:02:26.593

It would seem from 13.6 in the C++11 spec that clang is correct here:

13.6 Built-in operators [over.built]

The candidate operator functions that represent the built-in operators defined in Clause 5 are specified in this subclause. These candidate functions participate in the operator overload resolution process as described in 13.3.1.2 and are used for no other purpose. [ Note: Because built-in operators take only operands with non-class type, and operator overload resolution occurs only when an operand expression originally has class or enumeration type, operator overload resolution can resolve to a built-in operator only when an operand has a class type that has a user-defined conversion to a non-class type appropriate for the operator, or when an operand has an enumeration type that can be converted to a type appropriate for the operator. Also note that some of the candidate operator functions given in this subclause are more permissive than the built-in operators themselves. As described in 13.3.1.2, after a built-in operator is selected by overload resolution the expression is subject to the requirements for the built-in operator given in Clause 5, and therefore to any additional semantic constraints given there. If there is a user-written candidate with the same name and parameter types as a built-in candidate operator function, the built-in operator function is hidden and is not included in the set of candidate functions. — end note ]

:

For every cv-qualified or cv-unqualified object type T there exist candidate operator functions of the form

T& operator[](T *, std::ptrdiff_t);

T& operator[](std::ptrdiff_t, T *);

edit

Once you get past which operator functions exist, this just becomes standard overload resolution as described by section 13.3 of the standard -- about 10 pages of details, but the gist of it is that for a function call to not be ambiguous, there needs to be a single function that is at least as good a match as all the possible, viable functions on every argument, and a better match than the others on at least one argument. There's a lot of spec detail on exactly what 'better' means, but it boils down to (in this case) a match not requiring any user-defined conversion operator or object constructor is better than one which does.

So in this case, there are two viable matches:

void Something::operator[](const foo& f)
operator[](long, const char *)

The first is a better match for the first argument, while the second is a better match for the second. So unless there's some other function that is better than both of these, its ambiguous.

That latter point is a possble workaround -- add:

void operator[](const char *a) { return (*this)[foo(a)]; }

to class Something

I don't understand why it was important to ever have `T& operator[](std::ptrdiff_t, T *);` in C. — Neil G, Jan 18 '12 at 19:02
If I'm understanding this correctly. This explains why the built in operator is considered. But I'm also interested in why clang thinks the two are ambiguous and are not preferring one over another. I didn't say that in my question. I will add it. — ryaner, Jan 18 '12 at 19:03
Also for all we know, gcc and VC10 might also have considered the built in operators during overload resolution but think that it is not ambiguous and choose to call Something::operator[] , thus compilation succeeds, whereas clang thinks that the two are ambiguous (doesn't prefer one over another). — ryaner, Jan 18 '12 at 19:15
@Neil G: C doesn't have operator[] at all -- `a[b]` is syntactic shorthand for `*(a+b)` and is converted to the latter before even considering types. I guess your question equivalent to "why allow int+pointer as well as pointer+int", which I guess is just easier as `+` is normally commutative — Chris Dodd, Jan 18 '12 at 21:36
@ChrisDodd: Okay. I think that C and C++ should be fixed so that a[b] is always a `a[b]` operator, and that that operator should not exist for `a` is a numeric type. — Neil G, Jan 18 '12 at 21:43
@ChrisDodd Hi, I'm from the future and the "workaround" with `operator[](const char *a)` just helped me. Thanks! — screwnut, Aug 30 '22 at 18:31

score 4 · Answer 3 · answered Jan 18 '12 at 19:51

It seems there is no question that both Something::operator[](const foo& f) and the built-in operator[](long, const char *) are viable candidate functions (13.3.2) for overload resolution. The types of real arguments are Something and const char*, and implicit conversion sequences (ICFs) I think are:

for Something::operator[](const foo& f): (1-1) identity conversion, and (1-2) foo("32") through foo::foo(const char*);
for operator[](long, const char *): (2-1) long(double(d)) through Something::operator double() const (inherited from Base), and (2-2) identity conversion.

Now if we rank these ICFs according to (13.3.3.2), we can see that (1-1) is a better conversion than (2-1), and (1-2) is a worse conversion than (2-2). According to the definition in (13.3.3),

a viable function F1 is defined to be a better function than another viable function F2 if for all arguments i, ICSi(F1) is not a worse conversion sequence than ICSi(F2), ...

Therefore, neither of the considered two candidate functions is better than the other one, and thus the call is ill-formed. I.e. Clang appears to be correct, and the code should not compile.

Should this compile? Overload resolution and implicit conversions

3 Answers3

Linked