[rust-dev] Opt-In Built-In Traits

David Henningsson diwic at ubuntu.com
Thu Jul 24 23:30:43 PDT 2014

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 <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.

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 

> 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 */

pub struct foo2 {} /* Ok, copy behavior advertised */

pub struct foo3 {} /* Ok, move behavior advertised */

pub struct foo4 {} /* Compile error, move or copy behavior must be 
explicitly stated */

  // David

More information about the Rust-dev mailing list