Re: [boost] [futures] boost::futures

From: Braddock Gaskill (braddock_at_[hidden])
Date: 2007-03-14 11:27:48

On Wed, 14 Mar 2007 07:27:06 -0500, Hartmut Kaiser wrote:
> Braddock Gaskill  wrote:
> These operators should create a new (composite)future, exposing the same
> interface as the (simple) futures you're composing. This composite future
> should handle the exceptions in a similar way as the embedded ones, i.e.
> propagate the exceptions catched in the embedded futures to the caller, as
> appropriate.

So, that would mean that for f3 = f1 || f2, if f1 propagates an exception while
f2 succeeds, f3 still propagates an exception?

> Also, does your implementation of operator|| allow for constructs like f1 ||
> f2 || f3 ?

I don't have a real implementation of composition, I posted that simple
operator|| example out to show that it can be done without any changes to the
base future<T>/promise<T> implementation, so that they can proceed more or less
independently.  I'm hoping we can make use of an existing composition
implemenation. 

As I understand it, the point you riase is if you want f1 || f2 || f3 to have
the semantics of returning a future<variant<T1, T2, T3> > without modifiation
to the base future class.  I would think that could be done if
operator||(future<T1>, future<T2) actually returns a proxy class which is
implicitly convertible to a future, and properly specialized operator||
functions are provided.  I haven't given this much thought yet though.

But that raises another point with the variant/tuple semantics...if I do
f3 = f1 || f2;
f3 would then have the type future<variant<f1::type, f2::type> >.
If I then do a seperate
f5 = f3 || f4;

then does f5 have the type 
future<variant<f1::type, f2::type, f4::type> >, or
future<variant<variant<f1:type, f2::type>, f4::type> >?

Should there be a seperate future_group concept to disambiguate?

Composition overloading with || or && gets very hairy or impossible if the
current proposal to have a future implicitly convertable to it's value, with
blocking, goes through.  Maybe Peter has thoughts on this.

I like the tuples/variant idea of composition, but how do you handle exceptions?

The semantics of composition still seems far less settled than the basic future
concept, at least in my mind.  Any references are appreciated, I have seen very
few.  I would like to discuss it.  

Thanks for the feedback!
Braddock Gaskill
Dockside Vision Inc