Frank Mori Hess wrote:
Future<bool> operator||(const Future<T> &a, const Future<U> &b);
1. Why do you would do that? Do you have a use case?
Making active functions that take futures as arguments and return futures as return values is the primary feature of libpoet. See
http://www.comedi.org/projects/libpoet/
So the operator|| above would be used if you wanted to || two results and pass the result of the || to another active function without blocking waiting for the futures to become ready. Really it was just an example though, I'm not currently planning to implement this (although maybe I will someday if I discover it to be useful).
Passing the result of f1 || f2 does not block execution at all. F1 || f2 yields just another future you will have to dereference first to make it returning it's value (or blocking, if the value is not available). So I'ld rather cross the bridge, when I'm there. Relying on fictional use cases is at least questionable.
2. If you really have to do that, simply do not include the header(s) defining the operators.
I don't really have to define an operator||, I could just give the function an ordinary name. My point is, composing futures like in Thorsten Schütt's implementation doesn't really have to define an operator|| either. And, if I had to choose which function had a more legitimate claim to use operator||, I'd choose my example.
Not including the headers isn't really a solution, since it precludes the use of the conflicting functions in the same code.
This doesn't preclude anything. You said you don't _want_ to use the overloaded semantics of futures at all (because you don't like them). How this may then conflict with other code? I hold my point: just don't include the header containing the questionable operators and you don't have to pay for them.
Pointless overloading isn't a good thing. What does it buy you here? A pair of parenthesis.
Syntactic sugar improves expressiveness, which makes code more readable. But as always this is a matter of style and personal preference. I don't want to start a religious discussion here. Just don't use the syntactic sugar, if you don't like it. The usage of operator overloading has one advantage over a similar solution using functions, though. When combining futures you ultimately want to flatten the composed return types: i.e. for a f1 || f2 || f3 (with different return types T1, T2 and T3) you want to get a variant<T1, T2, T3> as the composite return type and not a variant<variant<T1, T2>, T3> (as you would get using simple functions taking two parameters). This naturally involves some meta template magic to construct the required return types. Using functions you'll have to do this by hand, using operators you can reuse existing meta-template frameworks like proto allowing to implement this with minimal effort. Regards Hartmut