Unwrapping shared_future

[hkaiser]

future now has an unwrapping constructor. I'd propose to add a similar unwrapping constructor to shared_future:

template <typename R> 
class shared_future {
// ...
    shared_future(future<shared_future<R>>&& f);
};

this constructor would expose semantics similar to those of its counterpart. We have that added to HPX and it has proven to be very useful.

[viboes]

Does HPX do implicit unwrapping of shared_future::then?

What is the result of shared_future<R1>::then() with a continuation that return shared_future<R2>?

With this unwrapping constructor I would expect it to be shared_future<R2>.

[K-ballo]

Does HPX do implicit unwrapping of shared_future::then?

We don't. We have gone back and forth with this and it isn't set in stone, but at least I feel that .then should always return a future owned by the calling code (that is, a future).

You can still get explicit unwrapping if you opt to have it.

[arturl]

I agree that we should have what @hkaiser proposes.

This got me thinking: should we also have a constructor on shared_future that takes shared_future<shared_future<R>>? I think not, because then doesn't do that, but it also reasonable to ask that then support unwrapping of shared_future.

BTW, these arguments were not considered by LEWG when it was recommended that we do away with explicit unwrap. We might have a reason to reconsider this now, but given how many times we flip-flopped on this, I don't want to change it again on a whim...

[viboes]

shared_future<shared_future<R>> appears as soon as you nest two functions returning a shared_future.

Maybe we can write a short paper to re-establish future/shared_future::unwrap independent from N4123.

[arturl]

This issue is resolved for Urbana, but I'll open a new one to consider unwrapping shared_future<shared_future<T>>

[viboes]

I agree.