In Rust, making something copyable is always explicit. I like that a lot.

To me it’s not really excitement so much as “oh god how do i make this ridiculous language do the correct thing”.

I think this all comes down to having the right mental model.

In this case, I think it helps to know that:

• returning by value by default implies making a copy,
• ...but if the output type supports move semantics and the function returns a temporary value (rvalue) then the language is on your side and tries to move it instead of doing a copy.
• and here's the kicker: now the language goes the extra mile and looks after you to avoid that copy, and if your return value allows the language to apply an optimization then the language is on your side and eliminates any potential copy without you having to do anything special.

The zany behavior is that if you set up your function to push for a move (i.e., force a local variable to be treated as a temporary), the language ceases to be able to apply its optimization.

That's basically it. No real mystery.

@QuadriLiteral @lysdexic We've been looking at a paper just recently in Kona, where the author proposed to not penalize "unfortunate" uses of std::move. I think this is user friendly and you might imagine what I've been voting for.

I wonder if the language could be updated so these extra std::move invocations actually become harmless? return std::move is something that I see used quite a bit.

These std::move invocations are harmless, as they only cast objects to their rvalue reference.

The destructive bit takes place in the type they are assigned to, as it invokes either a move constructor or a move assignment operator, and calling those implies that the object you just passed to std::move will be invalidated after the call and should not be used subsequently.