This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of C++14 status.

### 2186. Incomplete action on `async/launch::deferred`

Section: 33.10.9 [futures.async] Status: C++14 Submitter: Vicente J. Botet Escriba Opened: 2012-09-20 Last modified: 2017-07-05

Priority: Not Prioritized

View other active issues in [futures.async].

View all other issues in [futures.async].

View all issues with C++14 status.

Discussion:

The description of the effects of `async` when the launch policy is `launch::deferred` doesn't state what is done with the result of the deferred function invocation and the possible exceptions as it is done for the asynchronous function when the policy is `launch::async`.

[2012, Portland: move to Open]

Detlef: agree with the problem but not with the resolution. The wording should be applied to all launch policies rather than having to be separately specified for each one.

Hans: we should redraft to factor out the proposed text outside the two bullets. Needs to be carefully worded to be compatible with the resolution of 2120 (see above).

Moved to open

[Issaquah 2014-02-11: Move to Immediate after SG1 review]

Proposed resolution:

[This wording is relative to N3376.]

1. Change 33.10.9 [futures.async] p3 bullet 2 as indicated:

   >     template <class F, class... Args>
   >     future<typename result_of<typename decay<F>::type(typename decay<Args>::type...)>::type>
   >     async(F&& f, Args&&... args);
   >     template <class F, class... Args>
   >     future<typename result_of<typename decay<F>::type(typename decay<Args>::type...)>::type>
   >     async(launch policy, F&& f, Args&&... args);

   > > -2- Requires: […]

   > > -3- Effects:: The first function behaves the same as a call to the second function with a `policy` argument of `launch::async | launch::deferred` and the same arguments for `F` and `Args`. […] The further behavior of the second function depends on the `policy` argument as follows (if more than one of these conditions applies, the implementation may choose any of the corresponding policies):

   > > - if `policy & launch::async` is non-zero […]

   > > - if `policy & launch::deferred` is non-zero — Stores `DECAY_COPY(std::forward<F>(f))` and `DECAY_COPY(std::forward<Args>(args))...` in the shared state. These copies of `f` and `args` constitute a deferred function. Invocation of the deferred function evaluates `INVOKE(std::move(g), std::move(xyz))` where `g` is the stored value of `DECAY_COPY(std::forward<F>(f))` and `xyz` is the stored copy of `DECAY_COPY(std::forward<Args>(args))...`. Any return value is stored as the result in the shared state. Any exception propagated from the execution of the deferred function is stored as the exceptional result in the shared state. The shared state is not made ready until the function has completed. The first call to a non-timed waiting function (33.10.5 [futures.state]) on an asynchronous return object referring to this shared state shall invoke the deferred function in the thread that called the waiting function. Once evaluation of `INVOKE(std::move(g), std::move(xyz))` begins, the function is no longer considered deferred. [Note: If this policy is specified together with other policies, such as when using a policy value of `launch::async | launch::deferred`, implementations should defer invocation or the selection of the `policy` when no more concurrency can be effectively exploited. — end note]