Frank Mori Hess:
On Monday 02 June 2008 13:02 pm, Peter Dimov wrote:
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>
Oh, I came up with a reason that having future_value objects as inputs can be preferable to the solution you describe. Your solution forces the "lifted" functions to always take templates arguments. But template methods can't be made virtual. Also, you can't pass them to bind() without manually specifying all the template parameters.
Hm. I'm not sure I follow. Let's say that I have: struct A { virtual int f( long x ) = 0; }; int g(); future<int> h( A* pa ) { return async( &A::f, pa, async( g ) ); } What's the problem with the outer async recognizing that its third argument is a future and treating it as a dependency?