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.
Huon
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
