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.