On Wed, Jul 23, 2014, at 12:52 PM, David Henningsson wrote: > > > 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
What would this solve? Nobody who’s using a type is going to care about the keyword used to introduce the type, they’re only going to care about the behavior of the type. Using `datastruct` instead of `struct` will have zero impact on the people writing let x: Foo = y; Actually, the whole notion of having to intentionally describe on every struct whether you want it to be Copy is my biggest objection to opt-in traits. The API Stability / documentation aspect is great, but it does seem like a burden to people writing once-off structs. What I’d actually like to see is for private structs to infer things like Copy and for public structs to then require it to be explicitly stated. I don’t know how to do this in a way that’s not confusing though. -Kevin _______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
