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

From: Frank Mori Hess (frank.hess_at_[hidden])
Date: 2007-03-14 14:09:37

On Tuesday 13 March 2007 23:55 pm, braddock wrote:
> I'm looking for input.  I'd be willing to add additional functionality
> needed and progress it to the point where it could be formally submitted
> into boost if there is interest.  It could perhaps be merged into the
> existing futures implementation in the vault to add combined groups,
> etc.

> -add_callback() permits arbitrary functions to be called when the future
> is set.  This is needed to build non-intrusive compound waiting
> structures, like future_groups, or to better support continuation
> scheduling concepts, as in coroutines.

I'd prefer a signal/slot to add_callback().  That is: thread_safe_signals 
and moving to Boost.Signals when a thread-safe version is accepted. 

> TODO:
>
> The following class of sub-type assignments should be made possible, as
> discussed by Frank Hess and Peter Dimov on the list.
>
> class A {};
> class B : public A {};
> promise<shared_ptr<B> > p;
> future<shared_ptr<A> > f(p);

That isn't what I was talking about (although I agree it should be made 
possible).  But B doesn't have to be derived from A.  If you can do

A a;
B b = a;

then you should be able to do (without blocking)

promise<A> p;
future<A> fa(p);
future<B> fb = fa;

For example, if I have an active_function that returns a future<unsigned> 
then I should be able to pass that return value to an active_function that 
takes a future<int> as a parameter and it should "just work".

Another suggestion is to rename promise::set() (boring) to 
promise::fulfill() (makes me smile).  And if there is an opportunity to 
work the name "empty_promise" in as a class or a concept, that would be 
clever too.

Other things I would need to replace poet::future with your future class:

-Constructing a future from another with an incompatible template type via 
a user-supplied conversion function.  Useful for extracting future 
elements from future containers, for example.

-Adding a promise::fulfill() that accepts a future with a compatible 
template type.  The effect would be that promise::fulfill() would be 
called with the value from the future when it is ready.

-- 
Frank