2799. noexcept-specifications in shared_future

Section: 33.6.8 [futures.shared_future] Status: Resolved Submitter: Zhihao Yuan Opened: 2016-11-11 Last modified: 2017-11-10

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 33.6.7 [futures.unique_future]/3 as follows:

    -3- The effect of calling any member function other than the destructor, the move-assignment operator, or validthe 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 33.6.8 [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: […]