Re: [boost] [safebool] Can we generalize it and put it into utilities?

Subject: Re: [boost] [safebool] Can we generalize it and put it into utilities?
From: Vladimir Batov (vladimir.batov_at_[hidden])
Date: 2009-03-30 21:52:31

> Stewart, Robert <Robert.Stewart <at> sig.com> writes:

> I think "safe_bool" is the better spelling than "safebool" because "safe"
> and "bool" are separate words.

Understood. Although there are plenty of examples of new words made up of other
words: widespread, wholesale, cellphone, ... long list. This situation looks
similar to those many re-create vs. recreate, etc. Both are quite acceptable (I
think). I am on the fence with regard to safebool vs. safe_bool with a slight
tilt towards safebool. Steven favored safe_bool as well. Let's see if others
step forward liking safebool. If not, well, I'll change. :-)

> ... don't call the member function pointer. 
> That is, omit the parentheses:
> 
>    operator safe_bool<Foo>::type
>    { return safe_bool<Foo>(condition); }

I do not understand how the above (with parentheses omitted) can possibly work.
The original does not call the member function pointer. It is an implicit
conversion to that type. Same as 
 
operator safebool<Foo>::type() const
{ return safebool<Foo>::apply(c); }

I probably do not understand what you mean.

> "make" should be spelled "apply."  It's longer but more in keeping with
> the rest of Boost.

OK. Changed.

> There's certainly something to be said for avoiding the construction
> of a temporary in which to save the
> bool on which the implicit conversion operator depends.  
> Everything is simpler:

Yes, simpler... as far as the implementation goes. I do not believe it is as
applicable to the interface (which has the preference):

operator safebool<Foo>::type() const
{ return safebool<Foo>(c); }

operator safebool<Foo>::type() const
{ return safebool<Foo>::apply(c); }

To me (the user) #1 is shorter, looks simpler, reads more naturally and one
less word to remember. With *both* interfaces supported I am not sure it is
worth fighting for one or the other. Maybe, instead, we might dump one of the
following:

operator safebool<Foo>::type() const
{ return safebool<Foo>::apply(c); }

operator safebool<Foo>::type() const
{ return make_safebool<Foo>(c); }

Or we might keep both though. 

>...
> make_safe_bool<Foo>(c) would be easier written make_safe_bool(this, c), 
> with the compiler deducing
> Foo from this, but since the return type must already be spelled
> safe_bool<Foo>::type, then the function
> body can be spelled safe_bool<Foo>::apply(c) just as easily.

Yes, I prefer spelling safebool<> for consistency.

> Usage is now:
> 
>    struct Foo
>    {
>       ...
>       operator safe_bool<Foo>::type() const
>       { return safe_bool<Foo>::apply(condition); }
>       ...
>    };
> 
> That looks clean and consistent.

Apart from safebool vs. safe_bool we've got just that.

> ... It might be good to link to
> http://www.artima.com/cppsource/safebool.html, 
> Bjorn Karlsson's article on the subject, for background.

Added.

V.