Subject: Re: [boost] PR: Remove safe_bool idiom from boost.tribool
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2018-05-22 02:05:48
On 22/05/2018 13:25, Robert Ramey wrote:
>>> which to me looks like a perfectly reasonable thing to do.Â But using
>>> explicit would create a compile time error.
> I disagree.
I am not sure what you are disagreeing with here, unless you intended to
disagree with yourself?
>> 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.
> I think that tribool is/was designed to promote this and in this case I
> find it useful and natural.
No, it wasn't. The somewhat-implicit bool conversion (safe_bool) was
expressly for use within if statements, as demonstrated in the
Nowhere in this documentation will you find implicitly returning a
tribool as a bool.
Note that explicit bool is also designed to handle the case where used
in a conditional context in an implicit fashion, exactly the same as
Explicit bool also avoids the unintended side effects of implicit bool
conversions, such as promotion to integer (as pointed out by Peter) and
unintended narrowing when returning or passing parameters.
Implicitly returning a tribool as a bool should be forbidden for exactly
the same reasons as returning an int64_t as an int32_t -- you are losing
information, and unless you have explicitly indicated that this was
intended (presumably because you know things that the compiler does
not), it should be assumed to be a bug, perhaps as a result of a recent
change of types or just an oversight.
> I don't think explicit was created to fix safe_bool.Â In general I
> support usage of explicit.Â But in this case I don't think it's a good
The explicit keyword itself was not. But "explicit operator bool"
itself was, as part of C++11. (You can use the same keywords pre-C++11
but it will not have the correct effect.)
(Specifically, there's a loophole that allows implicit use of explicit
bool conversions when in a conditional context such as an if statement
where only a bool expression is valid.)
Thus "explicit" by itself disables all the unintended implicit usages of
the conversion, and C++11 then enables the one intended implicit use.
> Right.Â But then I'm imposing your view point on many users programs
> which already exist.Â You're basically changing the intention of
> tribool.Â You may well have a good argument that the very idea of
> tribool is a bad idea, that it should never have been made the way it
> was and that no one should use it, but that ship sailed long, long ago.
> It's not relevant here.
No, you're the one trying to change the intent.
Implicit bool conversions are a behavioural downgrade and will only
serve to introduce bugs. I can't believe this is even an argument.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk