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?