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

Subject: Re: [boost] PR: Remove safe_bool idiom from boost.tribool
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2018-05-21 23:49:52

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.

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.

This is exactly the reason why safe_bool was created in the first place, 
and why explicit bool was corrected in C++11 to match.

If you *want* that code to compile, then "return bool(tb);" (or use 
static_cast if you prefer) instead.  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, just better as it has proper compiler support instead of 
taking advantage of a hack to work around the previous defect in 
operator bool.

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, 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.