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.
Section: 30.6.7 [futures.unique_future] Status: Resolved Submitter: Alisdair Meredith Opened: 2009-03-12 Last modified: 2016-02-10
Priority: Not Prioritized
View all other issues in [futures.unique_future].
View all issues with Resolved status.
Addresses UK 334 [CD1]
Behaviour of get() is undefined if calling get() while not is_ready(). The intent is that get() is a blocking call, and will wait for the future to become ready.
[ Summit: ]
Agree, move to Review.
[ 2009-04-03 Thomas J. Gritzan adds: ]
This issue also applies to shared_future::get().
Add a paragraph to 30.6.8 [futures.shared_future]:void shared_future<void>::get() const;
Effects: If is_ready() would return false, block on the asynchronous result associated with *this.
[ Batavia (2009-05): ]
It is not clear to us that this is an issue, because the proposed resolution's Effects clause seems to duplicate information already present in the Synchronization clause. Keep in Review status.
[ 2009-10 Santa Cruz: ]
NAD Editorial. Addressed by N2997.
Add a paragraph to 30.6.7 [futures.unique_future]:
R&& unique_future::get(); R& unique_future<R&>::get(); void unique_future<void>::get();
Synchronization: if *this is associated with a promise object, the completion of set_value() or set_exception() to that promise happens before (1.10) get() returns.