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

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

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.

...

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

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.

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.

Hmmm - I did not know that. Since one of the main motivations of safe_bool is to inhibit this behavior, and it will shortly be inhibited by a C++17 in any case, it supports my argument for eliminating safe_bool idiom from tribool. Thanks for noticing this.

...

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.

Actually, all these cases are "case specific". I have views on the conversion to bool for optional an others, but we're only talking about tribool here.

...

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.

and implement a normal operator bool instead!

I would say I agree that the conversion operator is not a good idea with regard to tribool.

Hmmm - I'm proposing adding and ordinary conversion operator to convert tribool to bool. How can you agree with me while saying it's not a good idea?

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.

Sure we can disagree. I've made my argument - I think it's pretty clear. Robert Ramey