> The Foo& case won't compile. Const foo& will [compile] Not true. Both Foo& [1] and const Foo& [2] parameter types fail to compile (in gcc 8.5, I also tried g

> The Foo& case won't compile. Const foo& will [compile] Not true. Both Foo& [1] and const Foo& [2] parameter types fail to compile (in gcc 8.5, I also tried gcc 10 with same result). Bizarrely, in more modern compilers, including gcc 11, both Foo& [3] and const Foo& [4] do compile, even with the language version forced to C++11. I'm very curious to know why; presumably there's some defect report that got retroactively applied to all standards, but I can't find anything relevant. In any case, this illustrates how cryptic the C++ rvalue rules are. [1] https://godbolt.org/z/97Yse4jWY https://godbolt.org/z/97Yse4jWY [2] https://godbolt.org/z/Gsj83zes6 https://godbolt.org/z/Gsj83zes6 [3] https://godbolt.org/z/xWhG9cxKn https://godbolt.org/z/xWhG9cxKn [4] https://godbolt.org/z/xadn7Txh4 https://godbolt.org/z/xadn7Txh4 > Const foo& will as temporaries can bind to const references; this is desirable and x is still moved from. Well that (it's desirable) is your opinion! In my view, in an ideal world, f(move(x)) would not mean there is at least one move... it would mean there are at most zero copies.