Properly handle deferred futures

[hkaiser]

Currently, most of our facilities (wait_xxx, when_xxx, dataflow) do not properly handle deferred futures.

[hkaiser]

I think we need to execute the function associated with a deferred future, if the future is about to be destroyed and the value has not been retrieved. If this is not done, the associated function might never be executed.

[K-ballo]

The current implementation reflects what the standard mandates. This enables lazy evaluation, where unnecessary computations are not evaluated at all. We may want to differ from the standard here (we already do for launch::async, and the rationale for introducing launch::deferred does not apply to us either), but I think that deserves it's own issue.

[hkaiser]

Yah, by letting a future returned from async block if needed the standard implies this behavior for deferred futures as well. There was simply no need to add a special clause for launch::deferred as the general clause already covers the required behavior for deferred futures.

In our case however, we need special handling for deferred futures as otherwise the function associated with those might never execute.

[K-ballo]

That's not what I said, the blocking from futures applies to launch::async only. See: http://melpon.org/wandbox/permlink/cpMhTfbFu7lAs3FX

[hkaiser]

Well, let's close this issue and discuss it separately.