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.
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:
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.
? 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.