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