This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of C++14 status.

### 2185. Missing throws clause for `future/shared_future::wait_for/wait_until`

Section: 32.9.7 [futures.unique.future], 32.9.8 [futures.shared.future] Status: C++14 Submitter: Vicente J. Botet Escriba Opened: 2012-09-20 Last modified: 2021-06-06

Priority: Not Prioritized

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

View all issues with C++14 status.

Discussion:

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.

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

[2013-04-20, Bristol]

Accepted for the working paper

Proposed resolution:

[This resolution should not be adopted before resolving 2093]

[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 (32.9.9 [futures.async]), otherwise blocks until the shared state is ready or until the relative timeout (32.2.4 [thread.req.timing]) specified by `rel_time` has expired.

   > > -22- Returns: […]

   > > -??- Throws: timeout-related exceptions (32.2.4 [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 (32.9.9 [futures.async]), otherwise blocks until the shared state is ready or until the absolute timeout (32.2.4 [thread.req.timing]) specified by `abs_time` has expired.

   > > -24- Returns: […]

   > > -??- Throws: timeout-related exceptions (32.2.4 [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 (32.9.9 [futures.async]), otherwise blocks until the shared state is ready or until the relative timeout (32.2.4 [thread.req.timing]) specified by `rel_time` has expired.

   > > -24- Returns: […]

   > > -??- Throws: timeout-related exceptions (32.2.4 [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 (32.9.9 [futures.async]), otherwise blocks until the shared state is ready or until the absolute timeout (32.2.4 [thread.req.timing]) specified by `abs_time` has expired.

   > > -26- Returns: […]

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