[rust-dev] Mutable files

Huon Wilson dbau.pp at gmail.com
Tue Jul 22 17:35:56 PDT 2014

On 23/07/14 07:10, Tobias Müller wrote:
>> ... 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.

You can't just add Copy to anything: the contents has to be Copy itself, 
and, you can't have a destructor on your type (i.e. a Drop 
implementation removes the possibility to be Copy). Thus, almost all 
types for which by-value uses *should* invalidate the source (i.e. "move 
semantics") are automatically not Copy anyway.

The only way one can get a fatal error due to an incorrect Copy 
implementation is if the type with the impl is using `unsafe` code 
internally. In this case, that whole API needs to be considered very 
carefully anyway, ensuring correctness by avoiding Copy is just part of it.

I'll also note that an implementation of Copy just states the a 
byte-copy of a value is also a semantic copy, it doesn't offer any 
control over how the copy is performed. At runtime, by-value use of a 
Copy type is essentially identical to a by-value use of a non-Copy type 
(both are memcpy's of the bytes), the only major difference is the 
compiler statically prevents further uses of the source for non-Copy ones.


More information about the Rust-dev mailing list