Issue 2799: noexcept-specifications in shared

2799. `noexcept`-specifications in `shared_future`

Section: 32.10.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.]

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]

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: […]

2799. noexcept-specifications in shared_future

2799. `noexcept`-specifications in `shared_future`