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