Is this user-defined conversion not ambiguous? If so, what rule allows it?

Question

[C++11: 12.3/2]: User-defined conversions are applied only where they are unambiguous. [..]

Yet, the following compiles just fine in GCC and Clang trunk:

struct B;
struct A
{
    A();
    operator B();
};

struct B
{
    B(const A&);
};

int main()
{
    A a;
    (B)a;
}

What am I missing?

(question spawned from http://stackoverflow.com/q/22444415/560648) — Lightness Races in Orbit, Mar 17 '14 at 00:05
@PawełStawarz: Those are linker errors. It _compiled_ just fine. Add the `-c` switch if it makes you feel better :) — Lightness Races in Orbit, Mar 17 '14 at 00:08
Might be a duplicate of this: https://stackoverflow.com/questions/9661078/c11-ambiguity-between-converting-constructor-and-conversion-function-in-initi?rq=1 — jpw, Mar 17 '14 at 00:11
And following that link, the answer here seems to explain it: https://stackoverflow.com/questions/1384007/conversion-constructor-vs-conversion-operator-precedence/1384044#1384044 — jpw, Mar 17 '14 at 00:12
@billz: You mean, the other compiler in which there is no error message? ;P — Lightness Races in Orbit, Mar 17 '14 at 00:25

score 7 · Accepted Answer · answered Mar 17 '14 at 00:21

The cast notation (B)a is equivalent in this case to static_cast<B>(a) (§5.4/4). This in turn has the same semantics as the initialization B t(a), where t is a temporary (§5.2.9/4). Since B has class type, and the initialization is a direct-initialization, only the constructors of B are considered (§8.5/16). The applicable constructors are:

converting constructor B::B(const A&)
implicitly defined copy constructor B::B(const B&)
implicitly defined move constructor B::B(B&&)

The converting constructor wins overload resolution since the implicit conversion from A to const A& is an exact match.

Is this user-defined conversion not ambiguous? If so, what rule allows it?

1 Answers1

Linked