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