[rust-dev] Mutable files
troplin at bluewin.ch
Mon Jul 21 14:22:58 PDT 2014
Patrick Walton <pcwalton at 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.
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
> * 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
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?
More information about the Rust-dev