[rust-dev] Opt-In Built-In Traits (was: Mutable files)

Kevin Ballard 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
though.

-Kevin


More information about the Rust-dev mailing list