On 2014-07-21 19:17, Patrick Walton wrote:
On 7/21/14 8:49 AM, Tobias Müller wrote:
Patrick Walton <pcwal...@mozilla.com> wrote:
On 7/20/14 8:12 PM, David Henningsson wrote:
From a language design perspective, maybe it would be more
intuitive to
have different syntaxes for copy and move, like:
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.
* Causing a move when you thought you were copying results in a compiler
error.
* 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.
Again, we had that world before. It was extremely annoying to write
"move" all over the place. Be careful what you wish for.
I find these arguments compelling, but if what we want to accomplish is
a conscious choice between copy and move every time somebody makes a new
struct, maybe "#[Deriving(Data)] struct Foo" vs "struct Foo" is not
first-class enough.
Maybe the move vs copy should be done by using different keywords, a few
brainstorming examples:
* "datastruct" for copy, "struct" for move
* "simplestruct" for copy, "complexstruct" for move
* "struct" for copy, "class" or "object" for move
...etc.
// David
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
