Re: [boost] Updated version of futures library

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

> 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

Right, that's exactly my point.

> about short circuiting in time, as either the lhs or rhs futures
> complete.

Didn't we talk about operator&&()? No 'either/or' here, only both futures.
Additionally, the same comments apply as outlined below. 

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

No problem here. 

My main point was that such operator overloads apply to the result types and
not the futures themselves, which adds unnecessary semantics and defeats
separation of concerns. And, BTW, this is very much like the default
conversion operator to the result type for the futures which - as most have
agreed - is a bad idea. 

Regards Hartmut