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

Subject: Re: [boost] PR: Remove safe_bool idiom from boost.tribool
From: Robert Ramey (ramey_at_[hidden])
Date: 2018-05-22 01:25:44

On 5/21/18 4:49 PM, Gavin Lambert via Boost wrote:
> On 22/05/2018 02:53, Robert Ramey wrote:
>>> I'm strongly opposed to downgrading from safe_bool to implicit bool.
>>
>> I made my argument why this is good idea.  What's wrong with my argument?
> 
> Perhaps I missed something, but your argument seemed to be "safe bool 
> doesn't work in newer compilers" (so fine, use explicit bool instead, 
> since newer compilers do support that), and "explicit bool doesn't let 
> me write bad code" (so don't do that).
> 
>> This would/could break lot's of current code. Basically any code which 
>> looks like the following:
>>
>> bool f() {
>> Â Â Â Â Â tribool tb ...
>> Â Â Â Â Â return tb;
>> }
>>
>> which to me looks like a perfectly reasonable thing to do.  But using 
>> explicit would create a compile time error.

I disagree.
> 
> No, that's a perfect example of terrible code that should absolutely 
> generate a compiler error.  A narrowing conversion (from a source type 
> that can express more values than the destination type) should 
> absolutely *never* under any circumstances occur implicitly.

I think that tribool is/was designed to promote this and in this case I 
find it useful and natural.

> This is exactly the reason why safe_bool was created in the first place, 

safe_bool never corrected this and won't in C++11.

> and why explicit bool was corrected in C++11 to match.

I don't think explicit was created to fix safe_bool.  In general I 
support usage of explicit.  But in this case I don't think it's a good 
match.

> If you *want* that code to compile, then "return bool(tb);"

Hmmm - I don't think this actually depends upon implicit conversion of 
tribool to bool.

>(or use static_cast if you prefer) instead.

Right.  But then I'm imposing your view point on many users programs 
which already exist.  You're basically changing the intention of 
tribool.  You may well have a good argument that the very idea of 
tribool is a bad idea, that it should never have been made the way it 
was and that no one should use it, but that ship sailed long, long ago. 
It's not relevant here.

 Â  And this will work with both
> safe_bool and explicit bool.
> 
>>> I would be ok with #if logic that uses safe_bool on older compilers 
>>> and explicit bool on C++11 and up.
>>
>> This to me seems the worst.  It would mean that the semantics of 
>> tribool vary depending on which standard the compiler is adhering to.  
>> It would be impossible to discern the behavior of the code just by 
>> looking at it. You'd have to know which compile time switches are 
>> being used.
> 
> The semantics of explicit bool are the same as the semantics of 
> safe_bool, 

No they are not. And that's the exact problem. You can review my example 
above or check out this short video

https://www.youtube.com/watch?v=7uIyl_tDMkM

> just better as it has proper compiler support instead of 
> taking advantage of a hack to work around the previous defect in 
> operator bool.

but it's not the same thing.

> Personally, the thing I would most prefer is to get rid of any bool 
> conversion at all and require code to explicitly test tribools for 
> ==true/==false/boost::indeterminate, 

OK - but neither of us were around 15 years ago when it was reviewed. 
Unilateral changing it at this point would change the whole design and 
intention and break existing code. I don't see how that could possibly 
be acceptable.

Of course if you want to make and propose an alternative library named 
trilleam or something like that you're more than welcome.  But we can't 
trapse all over boost mucking up things wily nilly.

The change I propose:

a) won't change the current semantics of tribool as it relates to any 
currently working programs.
b) will address a current problem with tribool and gcc
c) will "recover" the trapping behavior of safe_bool with C++17

It's really a no-brainer.

> as people will usually disagree on 
> whether indeterminate should be truthy or falsy when forced to pick one. 
>  Â But I am not advocating that as I think the ship has long sailed.

Of course if you want to make and propose an alternative library named 
trilleam or something like that you're more than welcome.  But we can't 
trapse all over boost mucking up things wily nilly.

Robert Ramey