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

On 9 Sep 2014, at 12:45, Andrzej Krzemienski wrote:

2014-09-09 7:45 GMT+02:00 Dean Michael Berris :

...

On Tue Sep 09 2014 at 2:20:24 AM Andrzej Krzemienski wrote:

...

I went to see how Boost.Variant addresses this problem. Interestingly, it doesn't.

#include

struct Wrapper { operator int () { return 9; } operator boost::variant () { return 7; } };

int main() { boost::variant v = Wrapper(); assert(boost::get<int>(v) == 7); }

This program assertion-fails on MSVC.

Okay, that's interesting.

What's the process here, do we file a bug to Microsoft? Send in a defect report to the committee? Do we know the clauses in the standard that's supposed to make this "do the right thing"?

I filed this bug report: https://connect.microsoft.com/VisualStudio/feedbackdetail/view/967397/incorr...

I suppose MSVC 10.0 is no longer supported, but the same bug is present in all the newer versions of the compiler as well. The standard is clear about how the initialization should behave here, so the bug belongs to MSVC. It so obvious that I do not think that any reference to the standard is necessary. If the developers need it, I will provide

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)