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

Subject: Re: [boost] PR: Remove safe_bool idiom from boost.tribool
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2018-05-19 15:18:52

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. User's code
should be updated in this case.

> Attempts to resolve this were inconclusive.  This motivated me to think
> about why the safe_bool idiom was being used here at all.  According to
> articles on safe_bool articles this main reason is to support the common
> practice of using a not null value in a conditional:
>
> Testable t;
>
> if(t) ...
>
> without accidentally permitting things like
>
> if(t >> 1)...
>
> The above would occur if Testable included an operator bool () const member
> function.

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);

Some accidents are also prevented by the recent changes to the
language. For example, increment/decrement operations on bool are
deprecated since C++11 and removed since C++17.

> a) I don't think this idiom is a good idea and even more so in the context
> of modern C++.
>
> Conversion of a Testable instance to a bool instance should result in
> something that looks/acts like a C bool - not something else like a void *
> which C then maps to a bool.  If we want to use a bool for something like
> "is_valid" we'd be much better off just implementing is_valid directly.
> There would be then no confusion, side effects or hand a waving.

This is obviously very case-specific, but I find certain types like
smart pointers or optional rather natural to support explicit
conversion to bool. Such an operation has obvious meaning where the
conversion would apply. Having empty() or is_null() instead would just
increase verbosity for no gain.

Note that having a dedicated method is also useful in other contexts.
Like in my foo example above, when you actually want to call that
function with a bool that indicates whether Testable is valid or some
such.

> b) it's an especially a bad idea for tribool.
>
> The motivating concept behind tribool is that of some sort of "extended"
> bool. The naming suggests that it acts like a bool.  But since we've used he
> safe_bool idiom, it doesn't any more.  That is we can't use a tribool
> anywhere a bool is used. So if we use operator bool we'll get a tribool
> which acts like a bool - even when the original usage of bool was a bad idea
> according to a) above.  But at least we have the same behavior for tribool
> and bool which is a lot more intuitive and less confusing.
>
> Also, changing to operator bool () will address the current problem with GCC
> not supporting a constexpr version of tribool.
>
> Accordingly, I've submitted this PR to change the implementation of tribool
> to avoid the safe_bool idiom.

I would say I agree that the conversion operator is not a good idea
with regard to tribool. But I don't quite understand how making the
conversion _easier_ to invoke would make it better. If anything, I
would rather work towards removing the conversion operator entirely
instead of making it implicit. I think this change is a step in the
wrong direction.