Title
return type of async
Status
nad editorial
Section
[futures.async]
Submitter
Jonathan Wakely

Created on 2009-02-09.00:00:00 last changed 172 months ago

Messages

Date: 2010-10-21.18:28:33

Proposed resolution:

In [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 [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.

Date: 2010-10-21.18:28:33

Rationale:

Solved by N3058.

Date: 2010-10-21.18:28:33

[ 2010 Pittsburgh: ]

Moved to NAD Editorial. Rationale added below.

Date: 2010-02-12.00:00:00

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

Date: 2010-02-12.00:00:00

[ 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.

Date: 2010-02-12.00:00:00

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

Date: 2009-02-09.00:00:00

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 [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.

History
Date User Action Args
2010-10-21 18:28:33adminsetmessages: + msg1573
2010-10-21 18:28:33adminsetmessages: + msg1572
2010-10-21 18:28:33adminsetmessages: + msg1571
2010-10-21 18:28:33adminsetmessages: + msg1570
2010-10-21 18:28:33adminsetmessages: + msg1569
2010-10-21 18:28:33adminsetmessages: + msg1568
2009-02-09 00:00:00admincreate