Re: [rust-dev] Opt-In Built-In Traits
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 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.
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
Re: [rust-dev] Opt-In Built-In Traits (was: Mutable files)
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
Re: [rust-dev] Opt-In Built-In Traits (was: Mutable files)
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
