vector<future<T> > does not work gracefully with dataflow, when_all and unwrapped

[brycelelbach]

// Assume these definitions throughout:
hpx::future<boost::uint64_t> T;
std::vector<hpx::future<double> > U;

// I want to be able to use vectors of futures as arguments to my continuations;
// the vectors of futures will not be the only arguments, however. This does not
// seem to work with HPX currently.

// cfl0; HPX-free call signature. Enables the use of existing "local" kernels
// (e.g. small grains of work which are highly optimized - stuff that we don't
// want to break down into smaller chunks). Facilitates integration with legacy
// code without interface changes; this is an important point for large, existing
// codebases.
double cfl0(boost::uint64_t step, std::vector<double> u)

// cfl1; Call signature I am currently able to use with when_all d 
double cfl1(boost::uint64_t step, std::vector<hpx::future<double> > U);

// Won't compile; when_all/dataflow do not take vectors of futures for the tuple 
// call signature. You can pass a vector of futures if it is the only argument; 
// otherwise things seem to break. 
when_all(step, u);
dataflow(unwrapped(cfl0, step, u);

// Won't work; the second argumenet passed to the continuation is a vector 
// of futures, not a vector of values.
when_all(step, when_all(u)).then(unwrapped(cfl0));
dataflow(unwrapped(cfl0), when_all(u));

// Won't work; the 'step' argument needs 1 level of unwrapping, and the 'U' 
// argument needs 2 levels of unwrapping. unwrapped() does not support 
// mixed levels of unwrapping.
when_all(step, when_all(u)).then(unwrapped2(cfl0));
dataflow(unwrapped2(cfl0), step, when_all(u));

// Works. Ugly. Forces me to use the cfl1 call signature (or write another
// wrapper - but that would be redundant since we have unwrapped). The 
// cfl1 signature is not acceptable, because it has an hpx::future in it; it is 
// not an "HPX free" call signture. 
when_all(step, when_all(u)).then(unwrapped(cfl1)); 
dataflow(unwrapped(cfl1), step, when_all(u));

// Another major limitation; we only take std::vectors. Why not std::list, or 
// arbitrary Containers. I feel like perhaps we need to go the Spirit route, to
// some degree; we need a (much simpler) attribute grammar, which 
// supports nested futures and containers of futures.

[sithhell]

This is closely related to #1132.

[hkaiser]

Closed accidentally, reopening

[hkaiser]

Part of the issues above could be resolved by allowing for unwrapped to 'ignore' non-future arguments (to pass those through).

[hkaiser]

Moving this to the next milestone. This requires more discussions and decision making before it can be fixed.

[msimberg]

Is there something to be done here now that #2741 and #2829 are merged?

[hkaiser]

I think we can close this as the issue has been addressed by #2829.