Re: [boost] operator safe-bool?

From: Isaac Dupree (isaacdupree_at_[hidden])
Date: 2008-08-10 20:34:44

Daniel Frey wrote:
> On Sun, 2008-08-10 at 17:36 +0200, Mathias Gaunard wrote:
>> Isaac Dupree wrote:
>>> I'm looking at all these "operator unspecified_bool_type"s in Boost. 
>>> They vary:
>>>
>>> It's hard to get all of these right, and various Boost libraries have
>>> made changes in the past that got it wrong:
>>> type-safety
>>> compiler workarounds
>>> zero runtime overhead (a.k.a. more compiler workarounds)
>> At some time, there was a safe-bool thingy in Boost.Operators, but it
>> was removed.
>> I honestly do not know why.
> 
> The code that landed in CVS for a time is not based on the safe-bool
> idiom, but on an alternative approach: It simply adds a private
> declaration of an "operator signed char() const". When the used
> implements "operator bool() const", conversion to bool works while
> conversion to other types are ambiguous (e.g. int) or private (e.g.
> signed char).
> 
> The problem was that it broke is_convertible:
> is_convertible<A,int>::value resulted in a compile-time error instead of
> returning false - which is the reason why the code was removed from CVS
> before it was ever released.

argh! And there was a good reason for that private operator 
signed char.
Which is equivalent to providing several operator 
some-int()s for every builtin integral type.
If we did that, at least it would be just an access error 
rather than an ambiguity error*.
But I'm not sure if that helps us.  Conceivably, safe_bool 
could friend is_convertible
and is_convertible could special-case for it.  But how could 
it detect when a derived class actually does implement an 
operator?
Can is_convertible<T,int> where T is directly or indirectly 
derived from safe_bool<>, take the address &T::operator int, 
and then see whether the class type of the resulting value 
is of type safe_bool<> (in which case it's not convertible), 
or else it'll be of some derived type, in which case it is 
convertible.  I'm not sure if anything like that is possible 
in the standard, let alone the implementations we support. 
But maybe it is?  (for a large penalty in hack-ness.)

*  (Which might make the error messages better? or worse?)

-Isaac