Frank Mori Hess:
Oh, my use case is the "lifting of an ordinary function to an asynchronous one that takes/returns future_value objects" I mentioned earlier in the post. To be more specific:
http://www.comedi.org/projects/libpoet/boostbook/doc/boostbook/html/poet/act...
Hm. It would be nice if you could provide a better motivating example. :-) That aside, I'm not sure why you need future_value semantics. Let's assume that one has a primitive future<R> async( F f, A1 a1, ..., An an ); that schedules bind(f,a1,a2,...,an) for execution. It wouldn't be hard to make it recognize when Ai is future<Bi> and do the following instead: async_with_guard( bind( A1::ready, a1 ) && ..., f, bind( A1::get, a1 ), ... ); The 'guard' predicate is just symbolic since the scheduler would in reality store the futures as dependencies and use the appropriate "multi-multiwait". But the point is that I don't see the above requiring any future_value-specific operations. Or stated differently: future<double> fd1 = async( f1, 0 ); future<double> fd2 = async( f1, 1 ); future<double> fd = async( f2, fd1, 0.3, fd2, 0.7 ); // actually does: future<double> fd = async_with_dependencies( bind( f2, bind( future<double>::get, fd1 ), 0.3, bind( future<double>::get, fd2 ), 0.7 ), // function object fd1, fd2 ); // dependency list In this case one would need to use something like protect(fd1) if the function really takes a future. It's not clear whether the goal of libpoet is to provide fine-grained parallelism or lazy evaluation; if the latter, one could expect all functions to take futures, since an active_function provides no fine-grained laziness. In this case the above "activize by default" approach won't be very convenient.