https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61892
--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> --- (In reply to tower120 from comment #0) > I'm not sure that this is bug. But this is strange behavior, if you ask me. GCC's behaviour looks correct to me. If it looks strange to you it's because you have an unconstrained constructor template, and that is usually not a good idea. The return statement in f returns an rvalue, so the compiler selects a constructor that can be called with a non-const rvalue of type C. Your class has a user-defined destructor, therefore an implicit move constructor is not defined. C(Args...) cannot be instantiated as C<C>(C) to copy or move an object, as that would lead to infinite recursion, so when you have C(Args...) the implicitly-defined copy constructor C(const C&) is used for the return value, and it can be elided. When you declare C(Args&&...) that can be instantiated as C<C>(C&&) to construct the return value, but as that is not a copy constructor or move constructor it cannot be elided. When you declare a user-defined move constructor that will be used, and can be elided.
