Re: [boost] Updated version of futures library

From: Frank Mori Hess (fmhess_at_[hidden])
Date: 2008-06-01 07:42:19

On Sunday 01 June 2008 06:34, Felipe Magno de Almeida wrote:
> >> That's a matter of taste, for sure. But would you mind telling us why
> >> you don't want to have these? Your opinion sounds to be quite strong,
> >> so you must have good reasons!
> >
> > It's the obvious reason.  I don't think taking a function with a 2
> > letter name, which is already overloaded, and adding a new set of
> > overloads to it which have semantics completely unrelated to the
> > existing overloads is a desirable or aesthetically pleasing interface.
> >  No one would even consider doing such a thing if the function wasn't
> > an operator.  I guess I just don't find operator syntax as compelling
> > a feature as others.
>
> I tend to agree with Frank's view of overloading && and || for futures.
> I'm surely not a never-overload-operators-guy. I, for instance, love
> spirit. But in spirit && and || has a specific meaning inside EBNF
> domain. In futures, we're just inventing that meaning.
> Couldn't lambda's help us more than overloading here?

Oh, I came up with another reason.  A future can be empty (default 
constructed, or a moved unique_future).  Such classes often support 
converson to bool (or conversion to "unspecified boolean type" when they 
want to be safer) to test if they have been initialized.  So seeing a 
future in a logical operator, one might mistakenly assume the operator is 
is a test to see if either or both futures have been initialized.

Although, to nit-pick myself, I don't think the statement I made about the 
logical operators already being overloaded was technically correct.  I 
suppose its really the conversion-to-bool operator that is overloaded and 
there is just the bool prototype for the logical operators.