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

There are some problems with the description:

"If the type of the value is MoveAssignable the returned value is moved, otherwise it is copied."

  1. 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.
  2. Reducing MoveAssignable to the plain expression part std::is_move_assignable would 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 to std::is_move_constructible instead.

  3. 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 via std::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: