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

1050. Clarify postconditions for get_future()

Section: 32.10.6 [futures.promise] Status: Resolved Submitter: Alisdair Meredith Opened: 2009-03-12 Last modified: 2016-01-28

Priority: Not Prioritized

View all other issues in [futures.promise].

View all issues with Resolved status.

Discussion:

Addresses UK 340 [CD1]

There is an implied postcondition for get_future() that the state of the promise is transferred into the future leaving the promise with no associated state. It should be spelled out.

[ Summit: ]

Agree, move to Review.

[ 2009-04-03 Thomas J. Gritzan adds: ]

promise::get_future() must not invalidate the state of the promise object.

A promise is used like this:

promise<int> p; 
unique_future<int> f = p.get_future(); 
// post 'p' to a thread that calculates a value 
// use 'f' to retrieve the value. 

So get_future() must return an object that shares the same associated state with *this.

But still, this function should throw an future_already_retrieved error when it is called twice.

packaged_task::get_future() throws std::bad_function_call if its future was already retrieved. It should throw future_error(future_already_retrieved), too.

Suggested resolution:

Replace p12/p13 32.10.6 [futures.promise]:

-12- Throws: future_error if *this has no associated state the future has already been retrieved.

-13- Error conditions: future_already_retrieved if *this has no associated state the future associated with the associated state has already been retrieved.

Postcondition: The returned object and *this share the associated state.

Replace p14 32.10.10 [futures.task]:

-14- Throws: std::bad_function_call future_error if the future associated with the task has already been retrieved.

Error conditions: future_already_retrieved if the future associated with the task has already been retrieved.

Postcondition: The returned object and *this share the associated task.

[ Batavia (2009-05): ]

Keep in Review status pending Detlef's forthcoming paper on futures.

[ 2009-10 Santa Cruz: ]

NAD EditorialResolved. Addressed by N2997.

Proposed resolution:

Add after p13 32.10.6 [futures.promise]:

unique_future<R> get_future();

-13- ...

Postcondition: *this has no associated state.