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

### 1161. Unnecessary `unique_future` limitations

Section: 33.10.7 [futures.unique.future] Status: Resolved Submitter: LWG Opened: 2009-06-28 Last modified: 2021-06-06

Priority: Not Prioritized

View all other issues in [futures.unique.future].

View all issues with Resolved status.

Discussion:

Addresses UK 336

Description

It is possible to transfer ownership of the asynchronous result from one unique_future instance to another via the move-constructor. However, it is not possible to transfer it back, and nor is it possible to create a default-constructed unique_future instance to use as a later move target. This unduly limits the use of `unique_future` in code. Also, the lack of a move-assignment operator restricts the use of `unique_future` in containers such as `std::vector` - `vector::insert` requires move-assignable for example.

Suggestion

Add a default constructor with the semantics that it creates a `unique_future` with no associated asynchronous result. Add a move-assignment operator which transfers ownership.

Notes

Create an issue. Detlef will look into it.

[ 2009-07 Frankfurt ]

> Pending a paper from Anthony Williams / Detlef Vollmann.

[ 2009-10-14 Pending paper: N2967. ]

[ 2009-10 Santa Cruz: ]

> NAD Editorial Resolved. Addressed by N2997.

Proposed resolution: