What's the difference between treating a future as a placeholder and having a future implicitly convertibly to its result type? Doesn't a placeholder imply having this implicit conversion?
Yes, that's why I added it. I just think it's a little dangerous (see following paragraph). For example, boost::optional is a stand-in for its templated type, but it only supports implicit conversion from T to optional<T>, and not from optional<T> to T. Maybe a future_value should do the same.
That's exactly my point! For this reason I don't think having the default implicit conversion operator for futures is a good idea. But I'm starting to repeat myself. I so won't comment any further on this thread.
It's simply because the conversion can block, and thus produce unexpected behavior (an object appearing on the right hand side of an assignment stalling your program). The explicit future::get() at least gives a hint that something more than a quick conversion might be happening.
And just compare the amount of code needed to write something equivalent to (f1 || f2) && f3 using the proposed API from the link you gave me above. That's really appalling - certainly only IMHO!
I guess you're talking about Johan's initial proposal? In my current code, that is roughly
future_select(future_barrier(f1, f2), f3)
although that particular expression would produce a future<void> instead of a
future<tuple<variant<T1, T2>, T3>
If the user wanted composing functions or operators that returned tuples/variants, they could implement them without much trouble using future_combining_barrier. Unfortunately, I don't have any documentation or the latest version of my code online yet, but hopefully next week.
That's better than the initial proposal but still much more complicated than it could be: (f1 || f2) && f3. Just think about more complex logical execution constraints, these won't be readable anymore when using the function based syntax. Why do you object against using such a simple syntax, even if it's now obvious that it has additional advantages over your function based proposal (coherent return value treatment)? But again: I'm repeating myself, so there won't be any further comments from my side. If the authors of the future Boost futures library object against providing the logical operators it will be easy enough for me to implement those solely on top of the library... This is no reason for me to vote against it. But I will vote against a library implementing implicit conversion to the result type of the future: future<T> to T. Thanks for the insightful discussion. Regards Hartmut