Patrick Walton <pcwal...@mozilla.com> wrote: > On 7/21/14 8:49 AM, Tobias Müller wrote: >> As a rust newbie, that aspect aways makes me a bit nervous. Two quite >> different operations with the same syntax and and simply changing a detail >> in the struct can be enough to switch between the two. > > This is the reason for Opt-In Built-In Traits. > >> AFAIK this also was one of the reasons (if not _the_ reason) why >> std::auto_ptr was deprecated in C++. > > No, `auto_ptr` was deprecated because it copies, not moves, making it > hard to sensibly use in containers (among other things).
Quoting Andrei Alexandrescu on digitalmars.d: -------- We discussed this with Bartosz literally for weeks (him being a fan of auto_ptr for too long, later completely converted against it and I take credit for that :o)). With auto_ptr this was possible: auto_ptr<int> a(new int); auto_ptr<int> b = a; It would nullify a with copy syntax. That code won't compile with unique_ptr; you'd need an explicit move(a). It only got worse from there: passing into functions, member variables... MOVING WITH COPY SYNTAX DOES NOT WORK. It's cut and dried. Andrei --------- But you are right, Rust is not C++, it's actually the other way round that makes me nervous. > Comparisons between C++ aren't really relevant anyway because the > compiler catches any use-after-move at *compile time*, rather than at > runtime. This means that mistaking the two doesn't cause any harm: > > * Causing a move when you thought you were copying results in a compiler > error. > > * Causing a copy when you thought you were moving is harmless, as any > implicit copy in Rust has *exactly the same runtime semantics* as a > move, except that the compiler prevents you from using the value again. From a performance point of view that may be true, but you may lose desired semantics. If you want an instance of a type to be move-only, but later decide that copying that type is still useful in another place, then you lose the guarantee in the first place. It's just strange that you can change the semantic of an already existing operation just by adding new capabilities. Adding traits should define new operations with new semantics, not changing the semantics of existing operations. At least that's how it works for all other traits, and deviating from that is at least surprising. > Again, we had that world before. It was extremely annoying to write > "move" all over the place. Be careful what you wish for. Maybe the syntax was just too heavy? Tobi _______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
