2014-09-09 16:05 GMT+02:00 Pete bartlett
I'm not sure we should hold our breath waiting for fully general fix here. Not so long ago I ported a (admittedly huge) code base from MSC++ to standard C++ and there were many many instances of this issue - we called them "doubly-implicit conversions" - to be fixed. Ie cases where MS allows conversion chains but standard does not. Fixing these caused more pain than fixing the Windows API calls! I seriously doubt MS would break all the similar code that must be out there.
-maybe- something could be done in the limited case where the existence of a doubly-implicit conversion causes a compile time error due to ambiguity (as in the case posted to connect)
Yes, it is the limited case we need. Our problem here is the interaction between (1) double conversions and (2) overload ordering in the face of rvalue references. This correct problem does not compile on MSVC: struct A { A(int) {} A(A &&) {} }; struct B { operator A() { return A(1); } operator int() { return 0; } }; int main() { A t = B(); } Because the conversion path is ambiguous. I do not even mind that MSVC considers the double conversion, but I am pretty sure it should be ranked as worse than the direct binding from A to A&&. If I change the rvalue reference to lvalue reference: struct A { A(int) {} A(A const&) {} }; struct B { operator A() { return A(1); } operator int() { return 0; } }; int main() { A t = B(); } This program compiles fine. So it must be conversion path ranking. Regards, &rzej