PSA: Copy is becoming opt-in

community
1

There is a long-approved but also long-delayed breaking change coming down the pipeline. The idea is that struct/enum types will no longer be implicitly copyable, even if they contain POD data. They will move from place to place just like a Box etc.

For types that should be implicitly copyable, you can manually implement Copy. This can be done most easily by writing #[deriving(Copy)] (or, more likely, throwing Copy into a #[deriving] you already have).

There is also a lint that warns you if you have a type that could be copy but is not. The intention is to help you ensure that you do not forget to derive Copy when it is necessary. The idea is that if you have a type that is copyable but you don’t want to guarantee that for API compatibility, you can annotate it with a #[allow()].

This is part of the opt-in-builtin-types RFC.

UPDATE: See this note about a temporary feature-gate that may aid you in transitioning.

4 Likes
2

Does #deriving(Copy) derive Clone as well? The issue for this (https://github.com/rust-lang/rust/issues/17884) was last updated before multidispatch arrived.

3

#[deriving(Copy)] does not currently derive Clone as well. I would like to see #[deriving] take care of things like this (also PartialOrd vs Ord) but the issue is somewhat separate.

4

For convenience, I have also added a feature-gate opt_out_copy that lets you revert back to the old behavior. This can be used to keep older crates compiling while you transition them. Note though that this opt-out-copy behavior will eventually be removed.

5

Does the lint work for all type definitions or only for public ones?

6

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.