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

### 2027. Initialization of the stored task of a `packaged_task`

Section: 32.9.10.2 [futures.task.members] Status: C++11 Submitter: Alberto Ganesh Barbati Opened: 2011-02-09 Last modified: 2016-01-28

Priority: Not Prioritized

View all other issues in [futures.task.members].

View all issues with C++11 status.

Discussion:

Related with LWG issue 1514.

The move constructor of `packaged_task` does not specify how the stored task is constructed. The obvious way is to move-construct it using the task stored in the argument. Moreover, the constructor should be provided with a throws clause similar to one used for the other constructors, as the move constructor of the stored task is not required to be nothrow.

As for the other constructors, the terms "stores a copy of `f`" do not reflect the intent, which is to allow `f` to be moved when possible.

[2011-02-25: Alberto updates wording]

[2011-02-26 Reflector discussion]

Moved to Tentatively Ready after 5 votes.

Proposed resolution:

(wording written assuming LWG 1514 is also accepted)

1. Change 32.9.10.2 [futures.task.members] paragraph 3:

   > 3 Effects: constructs a new `packaged_task` object with an associated asynchronous state and stores a copy of `f` as the object's stored task initializes the object's stored task with `std::forward<F>(f)`. The constructors that take an `Allocator` argument use it to allocate memory needed to store the internal data structures.

2. Change 32.9.10.2 [futures.task.members] paragraph 5:

   > 5 Effects: constructs a new `packaged_task` object and transfers ownership of `other`'s associated asynchronous state to `*this`, leaving `other` with no associated asynchronous state. Moves the stored task from `other` to `*this`.