From: Frank Mori Hess (fmhess_at_[hidden])
Date: 2008-06-01 18:42:42
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.