On 2014-07-24 16:30, Kevin Ballard wrote:
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 moveWhat 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.
Is it the typing or the decision that would be a burden? My idea was mostly to reduce the typing compared to writing "Deriving(Data)" all the time.
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.
That's actually an interesting idea. Maybe something like this?
struct foo1 {} /* Ok, copy or move is inferred */
#[Deriving(Data)]
pub struct foo2 {} /* Ok, copy behavior advertised */
#[Deriving(NoCopy)]
pub struct foo3 {} /* Ok, move behavior advertised */
pub struct foo4 {} /* Compile error, move or copy behavior must be
explicitly stated */
// David _______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
