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.9.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 is `MoveAssignable` the 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."

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:

- `future::get()` returns the value `v` stored in the object’s shared state as `std::move(v)`. If the type of the value is `MoveAssignable` the returned value is moved, otherwise it is copied.

  …