Issue 2096: Incorrect constraints of future::get in regard to MoveAssignable (original) (raw)
This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of C++14 status.
2096. Incorrect constraints of future::get in regard to MoveAssignable
Section: 32.10.7 [futures.unique.future] Status: C++14 Submitter: Daniel Krügler Opened: 2011-11-02 Last modified: 2021-06-06
Priority: Not Prioritized
View all other issues in [futures.unique.future].
View all issues with C++14 status.
Discussion:
[futures.unique_future] paragraph 15 says the following:
R future::get();
…
-15- Returns:
future::get()returns the value stored in the object’s shared state. If the type of the value isMoveAssignablethe returned value is moved, otherwise it is copied.
…
There are some problems with the description:
"If the type of the value is MoveAssignable the returned value is moved, otherwise it is copied."
- It seems to impose unrealistic constraints on implementations, because how could an implementor recognize whether a user-defined type satisfies the semantics of
MoveAssignable? This should be based solely on a pure expression-based requirement, if this is an requirement for implementations. - Reducing
MoveAssignableto the plain expression partstd::is_move_assignablewould solvs (1), but raises another question, namely why a move-assignment should be relevant for a function return based on the value stored in the future state? We would better fall back tostd::is_move_constructibleinstead. - The last criticism I have is about the part
"the returned value is moved, otherwise it is copied"
because an implementation won't be able to recognize what the user-defined type will do during an expression that is prepared by the implementation. I think the wording is intended to allow a move by seeding with an rvalue expression viastd::move(or equivalent), else the result will be an effective copy construction.
[2011-11-28 Moved to Tentatively Ready after 5 positive votes on c++std-lib.]
Proposed resolution:
This wording is relative to the FDIS.
Change [futures.unique_future] paragraph 15 as indicated:
R future::get();
…
-15- Returns:
future::get()returns the valuevstored in the object’s shared state asstd::move(v).If the type of the value isMoveAssignablethe returned value is moved, otherwise it is copied.
…