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: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2009-03-31 10:33:50

On Monday, March 30, 2009 9:53 PM
Vladimir Batov wrote:
> > 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.

Your examples from English are valid (though my spelling checker wants to change "cellphone" to "cell phone" ;-).  However, if you compare Google results for "safe bool" with those for "safebool," subtracting noise from the latter, like hits on "safe bool," this Boost discussion, and "SafeBool," you'll see a distinct preference for "safe bool."  IOW, most usage modifies "bool" with the adjective "safe" rather than forming a new type named "safebool."

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

I kept seeing a return type and not a conversion operator.  I was looking past "operator" and manufactured a function name, apparently!  I was tired and unwell.  I'm sorry to confuse you.

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

Neither is complicated, I'll grant.  I just figured the class would be easier to understand in its simpler form and the usage is but slightly altered.

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

The former relies on creating a temporary and accessing a nested type, thus there's a slight inconsistency in using "safe_bool<Foo>."  The latter involves a static member function, rather than an instance, and the nested type, so "safe_bool<Foo>::" is used for both.  There's also no conversion operator to invoke.  It's just a more straightforward mechanism with more consistency between the return type and invocation, together making it slightly nicer.

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

I agree with Steven.  One interface is sufficient.  It would be nice to have more opinions, however.  I expect this will warrant a fast-track review, but you could hope for more opinions at that time, since few are available now.

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

>From that response, I'm unsure whether you took my point.  To be clear, given the choices,

  1) safe_bool<Foo>::apply(c) and
  2) make_safe_bool(this, c),

and the conversion type,

     safe_bool<Foo>::type,

1) is more consistent than 2), so we should eliminate 2).

_____
Rob Stewart                           robert.stewart_at_[hidden]
Software Engineer, Core Software      using std::disclaimer;
Susquehanna International Group, LLP  http://www.sig.com

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.