Use of overloaded operator '[]' is ambiguous with template cast operator

Question

The following code compiles well in gcc 7.3.0, but doesn't compiles with clang 6.0.0.

#include <string>

struct X {
    X() : x(10) {}
    int operator[](std::string str) { return x + str[0]; }
    template <typename T> operator T() { return x; } // (1) fails only in clang
    //operator int() { return x; } // (2) fails both in gcc and clang
private:
    int x;
};

int main() {
    X x;
    int y = 20;
    int z = int(x);
    return x["abc"];
}

I used command clang++ 1.cpp -std=c++98 with specifying different standard versions. I tried c++98,11,14,17,2a. In all cases an error is the same. Error message in clang is following:

1.cpp:14:13: error: use of overloaded operator '[]' is ambiguous (with operand types 'X' and 'const char [4]')
    return x["abc"];
           ~^~~~~~
1.cpp:5:9: note: candidate function
    int operator[](std::string str) { return x + str[0]; }
        ^
1.cpp:14:13: note: built-in candidate operator[](long, const char *)
    return x["abc"];
            ^
1.cpp:14:13: note: built-in candidate operator[](long, const volatile char *)
1 error generated.

What compiler correctly follows the standard in this situation? Is it a valid code?

The description of the problem can be found here, but it is about situation (2). I am interested in case (1).

`built-in operator[](long, const char *)` ... that's... what is going on...? — bolov, Feb 08 '19 at 11:41
To my knowledge there should be no ambiguity. What compiler do you use? — skyking, Feb 08 '19 at 11:42
@bolov https://timsong-cpp.github.io/cppwp/n4659/over.built#14 `T& operator[](std::ptrdiff_t, T*);`, no? — Language Lawyer, Feb 08 '19 at 13:22

xskxzr · Accepted Answer · 2019-02-11T06:49:31.650

GCC is wrong. The template case shouldn't make any difference.

[over.match.best]/1 says:

Define ICSi(F) as follows:

...

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. [over.best.ics] defines the implicit conversion sequences and [over.ics.rank] defines what it means for one implicit conversion sequence to be a better conversion sequence or worse conversion sequence than another.

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

The two viable candidates are

int         operator[](X&,             std::string); // F1
const char& operator[](std::ptrdiff_t, const char*); // F2

... and ICS1(F1) (X -> X&) is better than ICS1(F2) (X -> std::ptrdiff_t), no matter whether or not X -> std::ptrdiff_t is through a template conversion function, but ICS2(F1) (const char[4] -> std::string) is worse than ICS2(F2) (const char[4] -> const char*). So neither function is better than the other, resulting in ambiguity.

This has been reported as a GCC bug.

To be explicit (to help anyone else who might not get it immediately, like I didn't): There is an ambiguity, so the code should not compile. GCC doesn't recognize the template conversion function as a part of the valid conversion path for calling F2, so it doesn't see any ambiguity and compiles. This misrecognition is described in the linked GCC bug. — Danra, Feb 11 '19 at 11:47
The lesson of this as that you should not have a cast operator to any integral type for which you've also defined `operator []`. This is one of the C anachronisms that should be abandon IMHO. — Omnifarious, Feb 13 '19 at 05:56

score 6 · Answer 2 · edited Feb 08 '19 at 13:58

6

The issue is that there is one conversion on each path:

first from "abc" to std::string and then operator[] call.
second from x to std::ptrdiff_t and then the operator[] for an std::ptrdiff_t and a const char*.

So the solution is to make the conversion operator explicit:

int operator[](const std::string& str) { return x + str[0]; }
template <typename T>
explicit operator T() { return x; } // (1) fails only in clang

edited Feb 08 '19 at 13:58

Language Lawyer

3,378
1
12
29

answered Feb 08 '19 at 11:48

Matthieu Brucher

21,634
7
38
62

@LightnessRacesinOrbit fair enough. – Matthieu Brucher Feb 08 '19 at 11:50
@LightnessRacesinOrbit Sorry, not following your comment. – Matthieu Brucher Feb 08 '19 at 11:52
I mean that I'm no longer 100% sure because I missed that `x` is an `X` not a `long`. So another user-defined conversion is in play here – Lightness Races in Orbit Feb 08 '19 at 11:52
Yes, hence the `explicit` solution to make is work without adding extra literals. – Matthieu Brucher Feb 08 '19 at 11:53
Of course the explicit conversion has its own issues, but maybe better in the long run anyway. – Matthieu Brucher Feb 08 '19 at 11:56
Isn't conversion from `X` to `int` weaker than `const char*` to `std::string` because we use template here, not an exact function like in case (2)? Do you mean that all compilers should fail in situation (1)? – Feb 08 '19 at 12:02
I think that's one of the points @LightnessRacesinOrbit made in a comment. I don't know which one is correct (gcc or clang), maybe be worth opening a bug report with clang. – Matthieu Brucher Feb 08 '19 at 12:03
Meh, nah. I almost had it. But I'd have had to delve really deep into candidate matching. Time's up! Hopefully someone else can finish it :P – Lightness Races in Orbit Feb 08 '19 at 12:27
@BhavinChirag templates lose to non-templates during overload resolution, but I have found no template-based ranking of user-defined conversion sequences in the standard. – Language Lawyer Feb 08 '19 at 17:35

Use of overloaded operator '[]' is ambiguous with template cast operator

2 Answers2