Patrick Walton <pcwal...@mozilla.com> wrote: > On 7/21/14 2:22 PM, Tobias Müller wrote: >> 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.
Please don't snip the attribution, that was a quote! > ... in C++. Not in Rust. That's because, unlike C++, Rust is designed > from the ground up to support moves and copies in a first class way. > >> 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. > > Hence the Opt-In Built-In Traits proposal Opt-In built-In traits makes things a bit better but my point is still valid. By adding Copy (implicitly or explicitly) you remove the possibility of move semantics from the type. Usually you don't work alone on a project and some coworker adding Copy to a type that I expected to be Move may be fatal. No other trait removed works like that. >> Maybe the syntax was just too heavy? > > Any syntax at all is too much. I am convinced of that. I'm still not convinced but maybe my fear is unjustified. Time will tell. Tobi _______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
