2697. [concurr.ts] Behavior of future/shared_future unwrapping constructor when given an invalid future

Section: 99 [concurr.ts::futures.unique_future], 99 [concurr.ts::futures.shared_future] Status: Review Submitter: Tim Song Opened: 2016-04-22 Last modified: 2017-02-22

Priority: 2

View other active issues in [concurr.ts::futures.unique_future].

View all other issues in [concurr.ts::futures.unique_future].

View all issues with Review status.

Discussion:

Addresses: concurr.ts

In the concurrency TS, the future/shared_future unwrapping constructors

future(future<future<R>>&&) noexcept;
shared_future(future<shared_future<R>>&& rhs) noexcept;

appear to implicitly require rhs be valid (e.g., by referring to its shared state, and by requiring a valid() == true postcondition). However, they are also marked noexcept, suggesting that they are wide-contract, and also makes the usual suggested handling for invalid futures, throwing a future_error, impossible.

Either the noexcept should be removed, or the behavior with an invalid future should be specified.

Original resolution alternative #1 [NOT CHOSEN]:

This wording is relative to N4577.

Strike the noexcept on these constructors in 99 [concurr.ts::futures.unique_future]/1-2 and 99 [concurr.ts::futures.shared_future]/1-2, and optionally add a Requires: rhs.valid() == true paragraph.

[2016-11-12, Issaquah]

Sat PM: We prefer alternative #2 - Move to review

Proposed resolution:

This wording is relative to N4577.

Alternative #2: Specify that an empty (shared_)future object is constructed if rhs is invalid, and adjust the postcondition accordingly.

  1. Edit 99 [concurr.ts::futures.unique_future] as indicated:

    future(future<future<R>>&& rhs) noexcept;
    

    -3- Effects: If rhs.valid() == false, constructs an empty future object that does not refer to a shared state. Otherwise, cConstructs a future object from the shared state referred to by rhs. The future becomes ready when one of the following occurs:

    • Both the rhs and rhs.get() are ready. The value or the exception from rhs.get() is stored in the future's shared state.

    • rhs is ready but rhs.get() is invalid. An exception of type std::future_error, with an error condition of std::future_errc::broken_promise is stored in the future's shared state.

    -4- Postconditions:

    • valid() == truevalid() returns the same value as rhs.valid() prior to the constructor invocation..

    • rhs.valid() == false.

  2. Edit 99 [concurr.ts::futures.shared_future] as indicated:

    shared_future(future<shared_future<R>>&& rhs) noexcept;
    

    -3- Effects: If rhs.valid() == false, constructs an empty shared_future object that does not refer to a shared state. Otherwise, cConstructs a shared_future object from the shared state referred to by rhs. The shared_future becomes ready when one of the following occurs:

    • Both the rhs and rhs.get() are ready. The value or the exception from rhs.get() is stored in the shared_future's shared state.

    • rhs is ready but rhs.get() is invalid. The shared_future stores an exception of type std::future_error, with an error condition of std::future_errc::broken_promise.

    -4- Postconditions:

    • valid() == truevalid() returns the same value as rhs.valid() prior to the constructor invocation..

    • rhs.valid() == false.