shared_future is inconsistent with shared_ptrSection: 32.10.8 [futures.shared.future] Status: Resolved Submitter: LWG Opened: 2009-06-28 Last modified: 2021-06-06
Priority: Not Prioritized
View all other issues in [futures.shared.future].
View all issues with Resolved status.
Discussion:
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.
[ 2009-07 Frankfurt ]
Pending a paper from Anthony Williams / Detlef Vollmann.
[ 2009-10-14 Pending paper: N2967. ]
[ 2009-10 Santa Cruz: ]
NAD EditorialResolved. Adressed by N2997.
Proposed resolution: