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.
unique_future limitationsSection: 32.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: