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.

  …

[ 2011-11-28 Moved to Tentatively Ready after 5 positive votes on c++std-lib. ]

[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.