[rust-dev] Opt-In Built-In Traits (was: Mutable files)
kevin at sb.org
Thu Jul 24 07:30:20 PDT 2014
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 <pcwalton at 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
More information about the Rust-dev