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.

### 1163. `shared_future` is inconsistent with `shared_ptr`

Section: 32.9.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 Editorial Resolved. Adressed by N2997.

Proposed resolution: