Proposed resolution:

This wording is relative to N4606.

1. Change [futures.state] p7 as indicated:

   -7- When an asynchronous provider is said to abandon its shared state, it means:

   1. (7.1) — first, if that state is not ready or scheduled to be made ready at thread exit, the provider

      1. (7.1.1) — stores an exception object of type future_error with an error condition of broken_promise within its shared state; and then

      2. (7.1.2) — makes its shared state ready;

2. Change [futures.state] p10 as indicated:

   -10- Some functions (e.g., promise::set_value_at_thread_exit) delay making the shared state ready untilschedule the shared state to be made ready when the calling thread exits. This associates a reference to the shared state with the calling thread. The destruction of each of that thread's objects with thread storage duration ([basic.stc.thread]) is sequenced before making that shared state ready. When the calling thread makes the shared state ready, if the thread holds the last reference to the shared state, the shared state is destroyed. [Note: This means that the shared state may not become ready until after the asynchronous provider has been destroyed. — end note]

[ 2016-08-03, Billy O'Neal suggests concrete wording ]

Fri AM: Moved to Open

[ 2016-08-03 Chicago ]

This is related to 2530

promise::set_value_at_thread_exit and promise::set_exception_at_thread_exit operate on a shared state at thread exit, without making the thread participate in the ownership of such shared state.

Consider the following snippet:

std::promise<int>{}.set_value_at_thread_exit(42);

Arguably, since the promise abandons its shared state without actually making it ready, a broken_promise error condition should be stored in the shared state. Implementations diverge, they either crash at thread exit by dereferencing an invalid pointer, or keep the shared state around until thread exit.