Re: [boost] Updated version of futures library

From: Hartmut Kaiser (hartmut.kaiser_at_[hidden])
Date: 2008-05-31 14:30:01

Johan Torp wrote:

> >> Yes. I was trying to stay away from the overloaded operators, but
> this is certainly the same issue.
> >
> > Are you interested in something like this?
> > What's your reason for 'staying away' from the operators so far?
> 
> There has been some confusion as to what the operator semantics should
> be.
> Instead of returning the first ready future, one could return a future
> holding the value of lhs.get() && rhs.get() as soon as this is
> computable.
> 
> I.e.  future<bool> operator&&(future<bool>& lhs, future<bool>& rhs)
> would
> return a new future which is equal to true, iff lhs.get()==true and
> rhs.get()==true. If either one returned false it would be false and
> otherwise the composed future would not be ready yet.

Doing it the way you're proposing implies shortcutting operator&&(), which
can't be implemented. OTOH, writing fusion::vector<bool, bool> doesn't imply
this and is no deviation from the generic case.

> I think this is more natural semantics, but most people seem to think
> otherwise. Because of this confusion, I think we should leave the
> operators
> be. I believe this is what Anthony is referring to.
> 
> Note that if we let the operators map against the templated types
> operators
> as soon as they are computable, we could implement arithmetic operators
> too:
> future<double> a,b,c;
> future<double> d = a*(b+c*a); // Will become ready when a, b and c is
> ready
> This would allow "lifting" of aribitrary arithmetic expressions to
> futures.

This isn't possible in the generic case, because not all types provide the
corresponding operators. Additionally, this applies the operators to the
results and not the futures itself, where my proposal adds semantics for the
operators in terms of the futures and not their results.

Regards Hartmut