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 EditorialResolved. Addressed by N2997.

Proposed resolution: