> In both C++ and Rust, "moving" an object will still copy the struct fields, but
Most people consider a shallow copy a "copy", certainly a shallow copy isn't a "reference"! One of the big problems in this space is in fact the divergence of terminology that leads to arguments like this.
The introduction of move semantics to C++ was a terrible, terrible mistake; not because it doesn't solve a real problem but because the language is objectively much worse now as a routine tool for general developers. People used to hack on code to implement features, now they get confused over and argue about how many "&" characters they need in a function signature.
It was a problem that was best left unsolved, basically.
This is a good example of a hard-won life lesson... There might be a solution to a problem, but the solution is worse than the original problem. I semi-jokingly call this "the healing power of apathy". The reality of it is that, sometimes, there are problems in life where benign neglect is the best response.
Sounds like a skill issue. Maybe they should go shopping.
Jokes aside though, yeah, move semantics is taught bad. Once you start using it (say, with a unique_ptr in a container) it will quickly start making sense.
Most people consider a shallow copy a "copy", certainly a shallow copy isn't a "reference"! One of the big problems in this space is in fact the divergence of terminology that leads to arguments like this.
The introduction of move semantics to C++ was a terrible, terrible mistake; not because it doesn't solve a real problem but because the language is objectively much worse now as a routine tool for general developers. People used to hack on code to implement features, now they get confused over and argue about how many "&" characters they need in a function signature.
It was a problem that was best left unsolved, basically.