[ 2021-09-20; Jonathan updates wording to change the Throws: and attempt to align the Effects: with the deferred function case. ]

Previous resolution [SUPERSEDED]:

This wording is relative to N4892.

1. Modify [futures.async] as indicated:

   template<class F, class... Args>
     [[nodiscard]] future<invoke_result_t<decay_t<F>, decay_t<Args>...>>
       async(F&& f, Args&&... args);
   template<class F, class... Args>
     [[nodiscard]] future<invoke_result_t<decay_t<F>, decay_t<Args>...>>
       async(launch policy, F&& f, Args&&... args);
   

   -2- Mandates: […]

   -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 second function creates a shared state that is associated with the returned future object. 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):

   1. (3.1) — If launch::async is set in policy, calls invoke(decay-copy(std::forward<F>(f)), decay-copy(std::forward<Args>(args))...) ([func.require], [thread.thread.constr]) as if in a new thread of execution represented by a thread object with the calls to decay-copy being evaluated in the thread that called async. Any return value is stored as the result in the shared state. Any exception propagated from the execution of invoke(decay-copy(std::forward<F>(f)), decay-copy(std::forward<Args>(args))...)call to invoke is stored as the exceptional result in the shared state. [Note ?: Exceptions from the decay-copy calls are propagated to the caller. — end note] The thread object is stored in the shared state and affects the behavior of any asynchronous return objects that reference that state.

   2. […]