Section: 33.10.7 [futures.unique.future] Status: Resolved Submitter: Alisdair Meredith Opened: 2009-03-12 Last modified: 2021-06-06 18:38:24 UTC
Priority: Not Prioritized
View all other issues in [futures.unique.future].
View all issues with Resolved status.
Discussion:
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().
Suggested wording:
Add a paragraph to [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 EditorialResolved. Addressed by N2997.
Proposed resolution:
Add a paragraph to [futures.unique_future]:
R&& unique_future::get(); R& unique_future<R&>::get(); void unique_future<void>::get();Note:...
Effects: If is_ready() would return false, block on the asynchronous result associated with *this.
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.