Re: [boost] PR: Remove safe_bool idiom from boost.tribool

Subject: Re: [boost] PR: Remove safe_bool idiom from boost.tribool
From: Edward Diener (eldiener_at_[hidden])
Date: 2018-05-19 23:54:45

On 5/19/2018 1:22 PM, Andrey Semashev via Boost wrote:
> On Sat, May 19, 2018 at 7:09 PM, Robert Ramey via Boost
> <boost_at_[hidden]> wrote:
>> On 5/19/18 8:18 AM, Andrey Semashev via Boost wrote:
>>>
>>> On Sat, May 19, 2018 at 1:17 AM, Robert Ramey via Boost
>>> <boost_at_[hidden]> wrote:
>>>>
>>>>
>>>> One idea which has been tried is to use C++11 "explicit" as a substitute
>>>> from the safe_bool idiom.  Unfortunately this breaks legacy code.
>>>>
>>>> bool f(x) {
>>>>           return tribool(true); // fails
>>>> }
>>>>
>>>> So this is not a great solution either.
>>>
>>>
>>> C++11 explicit conversion operators don't support this use case, so if
>>> it works with the safe_bool idiom then it is either a bug or an
>>> unavoidable unfortunate limitation of the emulation.
>>
>> I don't think that one can conclude that because C++11 expicit conversion
>> operators don't support a use case that it's a bug. The question is whether
>> conversion to bool from tribool makes some sort of sense.  I think it does -
>> regardless of what C++11 actually does.
> 
> Explicit conversion operators are the evolution of the safe_bool
> idiom. In other words, it represents what we tried to achieve with
> safe_bool (and possibly failed in some aspects).
> 
>>> User's code should be updated in this case.
>>
>> This code has been in usage for 15 years. One can just start using the
>> explicit bool conversion and then break tons of code - some of it very old.
>> In one case (QT) this change generated 100's of syntax errors in existing
>> code.
> 
> I'm not saying this is going to be easy, but the change would be for
> the better, IMHO. We could offer some transition period.
> 
>>> There are also other accidents that are intended to be prevented by
>>> safe_bool/explicit conversion operators. For example:
>>>
>>>     void foo(bool f);
>>>
>>>     foo(t);
>>
>> Right - I get this.  I think this is a good conversion to support.  That is
>> why my change supports implicit conversion from tribool to bool.
> 
> I tried using tribool in my projects multiple times and every time I
> dropped it soon after the start in favor of an enum or something
> similar. The reason is that I can never readily tell how the
> conversion to bool works. The example above illustrates this rather
> well - I can never say what foo will receive if t is indeterminate.

It is documented that the:

"conversion to bool will be true when the value of the tribool is always 
true, and false otherwise."

So you always know how the conversion to bool works. Not reading the doc 
is not an excuse for not knowing.