On Sat, May 19, 2018 at 1:17 AM, Robert Ramey via Boost
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.