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

### 1510. Should be undefined behaviour to call `atomic_future` operations unless `valid()`

Section: 99 [futures.atomic_future] Status: NAD Editorial Submitter: INCITS Opened: 2010-08-25 Last modified: 2016-01-28

Priority: Not Prioritized

View all other issues in [futures.atomic_future].

View all issues with NAD Editorial status.

Discussion:

Addresses US-203

Both `future` and `shared_future` specify that calling most member functions on an object for which `valid() == false` produces undefined behavior. There is no such statement for `atomic_future`.

[ Resolution proposed by ballot comment: ]

Add a new paragraph after 99 [futures.atomic_future]/2 with the same words as [futures.shared_future]/3.

[ 2010-11-02 Daniel translates proposed changes into specific deltas and comments: ]

> While applying the wording, I notice that [futures.shared_future]/3 does speak of the move-assignment operator, and not of the copy-assignment operator. `atomic_future` obviously needs this to be true for the copy-assignment operator, but I strongly assume that `shared_future` needs to mention both special member assignment operators in this paragraph. To keep this consistent, the following P/R also provides wording to fix the corresponding location for `shared_future`.

Proposed resolution:

1. Change [futures.shared_future]/3 as indicated:

   > 3 The effect of calling any member function other than the destructor, the copy-assignment operator, the move-assignment operator, or `valid()` on a `shared_future` object for which `valid() == false` is undefined.

2. Following 99 [futures.atomic_future]/2, add a new paragraph:

   > ? The effect of calling any member function other than the destructor, the copy-assignment operator, or `valid()` on a `atomic_future` object for which `valid() == false` is undefined.