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.

### 2799. `noexcept`-specifications in `shared_future`

Section: 32.9.8 [futures.shared.future] Status: Resolved Submitter: Zhihao Yuan Opened: 2016-11-11 Last modified: 2021-06-06

Priority: 2

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

View all issues with Resolved status.

Discussion:

Addresses GB 62

There is an implicit precondition on most `shared_future` operations that `valid() == true`, 30.6.7p3. The list of exempted functions seems copied directly from class `future`, and would also include copy operations for `shared_futures`, which are copyable. Similarly, this would be a wide contract that cannot throw, so those members would be marked `noexcept`.

Suggested resolution:

Revise p3:

"The effect of calling any member function other than the move constructor, the copy constructor, the destructor, the move-assignment operator, the copy-assignment operator, or `valid()` on a `shared_future` object for which `valid() == false` is undefined." […]

Add `noexcept` specification to the copy constructor and copy-assignment operator, in the class definition and where those members are specified.

[2016-11-10, Zhihao Yuan comments and provides wording]

This resolution should close LWG 2697 as well, but that one was filed against concurrent TS.

[Issues Telecon 16-Dec-2016]

This is also addressed (but in a slightly different way by P0516R0

[2017-11 Albuquerque Wednesday issue processing]

Resolved by P0516, adopted in Issaquah.

Proposed resolution:

This wording is relative to N4606.

> [Drafting note: This change supersedes the 1st among 3 edits in LWG 2556, please omit that edit and apply the one below.]

1. Modify [futures.unique_future]/3 as follows:

   > -3- The effect of calling any member function other than the destructor, the move-assignment operator, or `valid` the member functions `get`, `wait`, `wait_for`, or `wait_until` on a `future` object for which `valid() == false` is undefined. [Note: Implementations are encouraged to detect this case and throw an object of type `future_error` with an error condition of `future_errc::no_state`. — end note]

2. Change [futures.shared_future] as indicated:

   > -3- The effect of calling any member function other than the destructor, the move-assignment operator, or `valid()`the member functions `get`, `wait`, `wait_for`, or `wait_until` on a `shared_future` object for which `valid() == false` is undefined. [Note: Implementations are encouraged to detect this case and throw an object of type `future_error` with an error condition of `future_errc::no_state`. — end note]

   > >     namespace std {
   > >       template <class R>
   > >       class shared_future {
   > >       public:
   > >         shared_future() noexcept;
   > >         shared_future(const shared_future& rhs) noexcept;
   > >         shared_future(future<R>&&) noexcept;
   > >         shared_future(shared_future&& rhs) noexcept;
   > >         ~shared_future();
   > >         shared_future& operator=(const shared_future& rhs) noexcept;
   > >         shared_future& operator=(shared_future&& rhs) noexcept;
   > >         […]
   > >       };
   > >       […]
   > >     }

   > […]

   >     shared_future(const shared_future& rhs) noexcept;

   > > -7- Effects: […]

   > […]

   >     shared_future& operator=(const shared_future& rhs) noexcept;

   > > -14- Effects: […]