Re: [boost] Updated version of futures library

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.