Title
shared_future is inconsistent with shared_ptr
Status
resolved
Section
[futures.shared.future]
Submitter
LWG

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

Messages

Date: 2010-12-05.14:14:49

[ 2009-10 Santa Cruz: ]

NAD EditorialResolved. Adressed 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 338

Description

shared_future is currently CopyConstructible, but not CopyAssignable. This is inconsistent with shared_ptr, and will surprise users. Users will then write work-arounds to provide this behaviour. We should provide it simply and efficiently as part of shared_future. Note that since the shared_future member functions for accessing the state are all declared const, the original usage of an immutable shared_future value that can be freely copied by multiple threads can be retained by declaring such an instance as "const shared_future".

Suggestion

Remove "=delete" from the copy-assignment operator of shared_future. Add a move-constructor shared_future(shared_future&& rhs), and a move-assignment operator shared_future& operator=(shared_future&& rhs). The postcondition for the copy-assignment operator is that *this has the same associated state as rhs. The postcondition for the move-constructor and move assignment is that *this has the same associated as rhs had before the constructor/assignment call and that rhs has no associated state.

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: + msg978
2010-10-21 18:28:33adminsetmessages: + msg977
2010-10-21 18:28:33adminsetmessages: + msg976
2009-06-28 00:00:00admincreate