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

Subject: Re: [boost] [optional] Changes in Boost.Optional
From: Pete bartlett (pete_at_[hidden])
Date: 2014-09-09 10:05:39

> On 9 Sep 2014, at 12:45, Andrzej Krzemienski <akrzemi1_at_[hidden]> wrote:
> 
> 2014-09-09 7:45 GMT+02:00 Dean Michael Berris <mikhailberis_at_[hidden]>:
> 
>> On Tue Sep 09 2014 at 2:20:24 AM Andrzej Krzemienski <akrzemi1_at_[hidden]>
>> wrote:
>> 
>>> 
>>> I went to see how Boost.Variant addresses this problem. Interestingly, it
>>> doesn't.
>>> 
>>> #include <boost/variant.hpp>
>>> 
>>> struct Wrapper
>>> {
>>>  operator int () { return 9; }
>>>  operator boost::variant<int, long> () { return 7; }
>>> };
>>> 
>>> int main()
>>> {
>>>  boost::variant<int, long> 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/incorrect-conversion-handling-in-c
> 
> 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)