Regarding the proposal "Simpler implicit move" (P2266R1), I'm not sure if I understand this new "move-eligible" things correctly.
Please correct these points if incorrect:
[LIVE]
std::forward
becomes optional for perfect forwarding the rvalue ref received
template<class T>
T&& seven(T&& x) { return std::forward<T&&>(x); }
becomes
template<class T>
T&& seven(T&& x) { return x; }
std::move
become optional for rvalue ref created locally
Widget&&
test_seven(Widget w) {
Widget&& rr = seven(std::move(w));
return std::move(rr);
}
becomes
Widget&&
test_seven(Widget w) {
Widget&& rr = seven(std::move(w));
return rr;
}
std::move
optionaly becomesparenthesis only
for return an rvalue ref for things created locally.
Widget&& h3(Widget t) {
return std::move(t);
}
becomes
Widget&& h3(Widget t) {
return (t);
}
Note: (3) : clang trunk warns of returning a local stack address at the time I post this.
Update 2021-08-02
https://github.com/cplusplus/papers/issues/968#issuecomment-915353127
https://isocpp.org/files/papers/P1018R13.html#P2266r1
Poll outcome: ✅ consensus. However, the against votes are from implementors, and bring relevant new information. This topic needs to be re-discussed, and might fail a plenary vote.
All three of the points are correct. In all cases, the variable in question is an implicitly movable entity (except
seven
if instantiated with an lvalue) and thus is treated as an xvalue.The parentheses here:
don't actually do anything. They would if the function returned
decltype(auto)
- since then without parentheses the function would returnWidget
(but still movet
, not copy it).