Re: [boost] [optional] Changes in Boost.Optional

Subject: Re: [boost] [optional] Changes in Boost.Optional
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2014-09-10 03:25:26

2014-09-09 16:05 GMT+02:00 Pete bartlett <pete_at_[hidden]>:

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