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

[ 2017-11 Albuquerque Wednesday issue processing ]

Resolved by P0516, adopted in Issaquah.

[ Issues Telecon 16-Dec-2016 ]

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

[ 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.

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.