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

### 1315. return type of `async`

Section: 33.10.9 [futures.async] Status: NAD Editorial Submitter: Jonathan Wakely Opened: 2009-02-09 Last modified: 2016-01-28

Priority: Not Prioritized

View other active issues in [futures.async].

View all other issues in [futures.async].

View all issues with NAD Editorial status.

Discussion:

Both overloads of `async` return `future<typename F::result_type>` which requires that `F` has a nested type. This prevents `async` being used with function pointers and makes the example in 33.10.9 [futures.async] invalid. I believe this is unintentional.

The proposed resolution also addresses editorial issues with the `launch_policy` function parameter.

For the first overload it is not sufficient to return `future<typename result_of<F(ArgTypes...)>::type>`. Calling `async(launch::xxx, foo, bar)` performs argument deduction on both `async` overloads, which for the first overload attempts to instantiate `result_of<launch(F, ArgTypes...)>`, which is invalid. SFINAE must be used to prevent that.

[ 2010-02-12 Moved to Tentatively Ready after 5 positive votes on c++std-lib. ]

[ 2010-02-12 Daniel opens: ]

> [..] if `decay<F>::type` is of type `std::launch`.

> or

> [..] if `remove_cv<remove_reference<F>::type>::type` is of type `std::launch`.

> The latter is the more specific form, but the former is equivalent to the latter for all cases that can occur here. I suggest to use the former for simplicity, but expect that implementations can effectively use the latter.

[ 2010-02-12 Moved to Tentatively Ready after 5 positive votes on c++std-lib. ]

[ 2010 Pittsburgh: ]

> Moved to NAD Editorial. Rationale added below.

Rationale:

Solved by N3058.

Proposed resolution:

In 33.10.1 [futures.overview] paragraph 1:

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

In 33.10.9 [futures.async] before paragraph 1

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

> > ...

> > Remarks: The first signature shall not participate in overload resolution if `decay<F>::type` is `std::launch`.