Boost logo

Boost :

Subject: Re: [boost] PR: Remove safe_bool idiom from boost.tribool
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2018-05-22 06:17:54

On 22/05/2018 17:23, Robert Ramey wrote:
> On 5/21/18 7:05 PM, Gavin Lambert wrote:
>> No, it wasn't.  The somewhat-implicit bool conversion (safe_bool) was
>> expressly for use within if statements, as demonstrated in the
>> documentation
>> ( Nowhere
>> in this documentation will you find implicitly returning a tribool as
>> a bool.
> I doesn't have to since void * (safe_bool) can be converted implicitly
> as bool. And there are many, many cases where this is done.  You might
> not think this is a great idea, but it's a fact.  These programs will
> fail to compile if you change safe_bool to explicit.

The intended purpose of safe_bool implicitly converting to bool was for
use in conditional expression contexts.

That it permitted other narrowing conversions is not intended and is

> Now you're re-hashing the design of tri-bool.  It works the way it has
> for many, many years.  Its consistent with other components such as
> std::optional which do the same thing and what many people are happy
> with.

std::optional was added after C++11 and as such uses explicit bool. It
does not have implicit conversions.

Older versions of boost::optional did use safe_bool, but have since been
updated to use explicit bool where compiler-supported (via macro

So both of these support my argument, not yours.

(Perhaps the better PR would be to make tribool use that macro, defined
in boost/core/explicit_operator_bool.hpp)

> actually "explicit" can be applied to conversion operators of all types
> - intrinsic as well as user defined.  I'm sure there was no intent to
> think in terms of "explicit bool" as some special situation.

I'm referring to the contextual bool conversion mentioned later on. It
is indeed a special situation.

>> (You can use the same keywords pre-C++11 but it will not have the
>> correct effect.)
> Hmmm - I was not  aware that "explicit" could be applied to conversion
> operators before C++11.

True, I misspoke; I was thinking of explicit constructors, which don't
apply here as it's the wrong conversion direction.

> LOL - Right.  That's the root of the whole discussion.  At some point
> long ago everyone thought these implicit conversions were a good idea.
> I presume they still do as we have optional which include implicit
> conversions to bool and I'm sure there are some more.

Implicit widening conversions can still be a good idea. Implicit
narrowing conversions never are. And again optional does not do what
you claim.

>> Thus "explicit" by itself disables all the unintended implicit usages
>> of the conversion, and C++11 then enables the one intended implicit use.
> Hmmm - I thought that C++11 enables implicit conversion of any integer
> or pointer to a bool for purposes of if, when etc.

Anything that is explicitly convertible to bool, yes. That doesn't
invalidate my point.

> maybe for components like optional, but I don't see it happening for
> tribool. continuing to permit tribool implicitly convert to bool - as it
> currently - won't introduce any more bugs than it does currently - if
> there are any.

This is incorrect, as Peter already pointed out.

Additionally, you should consider the effect on future code -- it's not
really a great argument to claim that a safety railing is no longer
necessary because nobody has fallen off the cliff while the safety
railing was there.

> b) move to explicit when supported. - which eliminates the compile error
> but makes behavior dependent to the C++ standard used to compile.  It
> will also break a lot of current user code.

This is the only option that makes sense to me. If that breaks user
code, it is a net positive effect because that code was already broken
-- and it is trivial to correct it where actually intended.

This is no different than when boost::optional switched to explicit
bool, to use your own example correctly.

> c) implement inplicit conversion to bool.  This breaks no current code
> and resolves the current constexpr issue.  It does permit t + u where t
> and u are results of bool conversions.  This will be fixed automatically
> for C++17.

As far as I am aware, this is not correct; bool is still implicitly
convertible to int in all versions of C++.
(And agrees.)

I welcome proof otherwise; although that still would not change my
opinion as it doesn't help those using pre-C++17 compilers.

Boost list run by bdawes at, gregod at, cpdaniel at, john at