This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of NAD status.

### 2046. `shared_future(future<R>&&)` should be allowed to throw

Section: 33.10.8 [futures.shared.future] Status: NAD Submitter: Peter Sommerlad Opened: 2011-04-04 Last modified: 2021-06-06

Priority: Not Prioritized

View all other issues in [futures.shared.future].

View all issues with NAD status.

Discussion:

Requiring the constructor `shared_future(future<R>&& rhs)` not to throw is a pessimisation of the case where a future is returned from a call to `async(function,launch::deferred)` and possible other cases.

Such a future not dealing with multiple threads only needs to keep (a copy of) the function to be called it later. However, creating a `shared_future` from that future will require more infrastructure, like space for the value of type `R`, an `exception_ptr`, and a synchronized reference counter for the `shared_future`'s instances.

Enforcing the constructor `shared_future(future<R>&& rhs)` not to throw, implies that any implementation of `future` will need to pre-allocate space for `shared_future`'s infrastructure, that also requires an operating system resource for synchronization, regardless if is ever needed.

All this came up when discussing D/N3267 and Concurrency Working Group decided that the constructor `shared_future(future<R>&& rhs)` should be allowed to throw.

[ 2011 Bloomington ]

Closed as NAD. Rationale to follow by email...

Proposed resolution:

Apply the proposed resolution of n3269