[patch] Use a more idiomatic bool operator in ErrorOr

[David Blaikie]

On Thu, Jan 16, 2014 at 10:38 AM, Alp Toker <alp at nuanti.com> wrote:

>
> On 16/01/2014 18:20, Aaron Ballman wrote:
>
>> On Thu, Jan 16, 2014 at 1:13 PM, Alp Toker <alp at nuanti.com> wrote:
>>
>>> On 16/01/2014 18:05, Reid Kleckner wrote:
>>>
>>>> With the impending switch to C++11, feel free to cleanup instances of
>>>> this
>>>> safe bool idiom.
>>>>
>>>
>>> Very unfortunate news on that front: explicit operators aren't support
>>> until
>>> MSVC 2013.
>>>
>>>    http://msdn.microsoft.com/en-us/library/hh567368.aspx
>>>
>>> That means LLVM_EXPLICIT will still be defined to nothing on MSVC 2012,
>>> resulting in inappropriate conversions taking precedence over the bool
>>> operator.
>>>
>> At least the 2013 build bot will still catch problems if it's misused,
>> but good point about using the compatibility macro.
>>
>
> Yes, I switched it on for MSVC 2013 back in r198142, along with updates to
> the other macros.
>
> That said, the current setup is a little dangerous and the only fully safe
> use I can see of the macro is for the benefit of sub-projects that have
> already pushed ahead and dropped MSVC 2012.
>
> In common use when the macro is turned off it's entirely possible an int
> conversion will silently be chosen leading to runtime brokenness :-/
>

Do we have types with any such dangerous duplicate conversions? I'd say
that's likely bad design even in a world with explicit bool conversion &
I'd treat those as code/design bugs and on that basis I'd still prefer to
nuke safe bools and use LLVM_EXPLICIT entirely.


>
> Perhaps we should document this. Thoughts?
>
> Alp.
>
>
>
> --
> http://www.nuanti.com
> the browser experts
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140116/438ab2c8/attachment.html>