On Sunday 01 June 2008 14:43, Hartmut Kaiser wrote:
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.
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.