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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk