To me it’s not really excitement so much as “oh god how do i make this ridiculous language do the correct thing”.
I’m way more scared of rogue implicit copy constructors. I wonder if cppfront has any plan to fix problems like implicit copy and pessimising move.
In Rust, making something copyable is always explicit. I like that a lot.
Copy has a very different meaning between the two languages. In rust the equivalent of a c++ copy is a clone() call for anything non trivial
…which is also explicit.
@BatmanAoD @Miaou It is just what you are used to.
In C++ everything is a copy. Sometimes the compiler optimizes it away. clang-tidy may help. Having a clone() is very C-like.
Cpp should have done ref by default and had & for copy, but here we are.
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.
@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.
That sounds great!
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::moveinvocations 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::movewill be invalidated after the call and should not be used subsequently.I mean harmless in a way that using std::move on the return type doesn’t prevent RVO?
