Title
Unnecessary unique_future limitations
Status
resolved
Section
[futures.unique.future]
Submitter
LWG

Created on 2009-06-28.00:00:00 last changed 171 months ago

Messages

Date: 2010-12-05.14:14:49

[ 2009-10 Santa Cruz: ]

NAD EditorialResolved. Addressed by N2997.

Date: 2009-10-14.00:00:00

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

Date: 2010-12-05.14:14:49

[ 2009-07 Frankfurt ]

Pending a paper from Anthony Williams / Detlef Vollmann.

Date: 2009-06-28.00:00:00

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.

History
Date User Action Args
2010-12-05 14:14:49adminsetstatus: nad editorial -> resolved
2010-10-21 18:28:33adminsetmessages: + msg970
2010-10-21 18:28:33adminsetmessages: + msg969
2010-10-21 18:28:33adminsetmessages: + msg968
2009-06-28 00:00:00admincreate