[ This wording is relative to N3376. ]

1. Change [futures.unique_future] as indicated:

   template <class Rep, class Period>
   future_status wait_for(const chrono::duration<Rep, Period>& rel_time) const;
   

   -21- Effects: none if the shared state contains a deferred function ([futures.async]), otherwise blocks until the shared state is ready or until the relative timeout ([thread.req.timing]) specified by rel_time has expired.

   -22- Returns: […]

   -??- Throws: timeout-related exceptions ([thread.req.timing]).

   template <class Clock, class Duration>
   future_status wait_until(const chrono::time_point<Clock, Duration>& abs_time) const;
   

   -23- Effects: none if the shared state contains a deferred function ([futures.async]), otherwise blocks until the shared state is ready or until the absolute timeout ([thread.req.timing]) specified by abs_time has expired.

   -24- Returns: […]

   -??- Throws: timeout-related exceptions ([thread.req.timing]).

2. Change [futures.shared_future] as indicated:

   template <class Rep, class Period>
   future_status wait_for(const chrono::duration<Rep, Period>& rel_time) const;
   

   -23- Effects: none if the shared state contains a deferred function ([futures.async]), otherwise blocks until the shared state is ready or until the relative timeout ([thread.req.timing]) specified by rel_time has expired.

   -24- Returns: […]

   -??- Throws: timeout-related exceptions ([thread.req.timing]).

   template <class Clock, class Duration>
   future_status wait_until(const chrono::time_point<Clock, Duration>& abs_time) const;
   

   -25- Effects: none if the shared state contains a deferred function ([futures.async]), otherwise blocks until the shared state is ready or until the absolute timeout ([thread.req.timing]) specified by abs_time has expired.

   -26- Returns: […]

   -??- Throws: timeout-related exceptions ([thread.req.timing]).

[ This resolution should not be adopted before resolving 2093 ]

[ 2013-04-20, Bristol ]

Accepted for the working paper

[ 2012, Portland: move to Review ]

The phrase timeout-related exception does not exist.

2093 was put in review, and there is some dependency here with this issue.

If you provide a user-defined clock that throws, we need to put back an exception to allow that to be done.

We will put this in review and say that this cannot go in before 2093.

The functions future::wait_for, future::wait_until, shared_future::wait_for, and shared_future::wait_for can throw any timeout-related exceptions. It would be better if the wording could be more explicit. This is in line with the changes proposed in LWG 2093's Throws element of condition_variable::wait with predicate.