Re: [boost] Updated version of futures library

From: Frank Mori Hess (fmhess_at_[hidden])
Date: 2008-05-31 16:59:27

On Saturday 31 May 2008 14:30, Hartmut Kaiser wrote:
> > 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. 

left-to right evaluation can't be short-circuited, but he's talking about 
short circuiting in time, as either the lhs or rhs futures complete.

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

So?  That just means something like

future<A> fa;
future<B> fb;
future<C> fc;
fc = fa + fb;

will compile if and only if

A a;
B b;
C c;
c = a + b;

compiles.  What's the problem with that?