RFC: changes to implicit copyability

[metajack]

Right now any struct that contains only implicitly copyable types is implicitly copyable and there is no way to turn this off.

We need a way to annotate that a struct should not be implicitly copyable at the very least.

I think a better solution would to make the default not to have structs be implicitly copyable unless annotated specifically that they are. That is, the default would be reversed.

This is an issue for things like Option where T is implicitly copyable. It completely changes the semantics of functions like unwrap(). Depending on the type of T, this may move or copy.

This recently caused a Servo bug where the different between unwrap() and with_mut_ref() caused an infinite loop:

sammykim/servo@7a1493a

[metajack]

nominating backwards compat

[bluss]

Including std::util::NonCopyable as a member in your struct will "make the annotation". It's zero-sized, so it should be just fine.

[catamorphism]

Accepted for backwards-compatible

[thestinger]

I think the current situation is the best compromise between all the competing interests. At the moment, you can explain the copy/move semantics as follows:

Rust uses shallow copies for assignment, parameter passing and returning. If the type contains &fn, &mut or a destructor, it will move ownership and the source will no longer be usable.

Any extra complications at a language level have a very real cost in complexity.

[bluss]

by the way, std::util::NonCopyable's destructor does not inline (and disappear) like one would expect. This is something that should be improved so that the annotation doesn't have this unintended small cost.

[alexcrichton]

We now have efficient markers introduced in #11768 for opting out of implicit copyability.

Nominating for closure, I don't think we want to modify the rules to opt-in to implicit copyability.

[pnkfelix]

Note that the marking struct has been renamed to std::kinds::markers::NoPod.

Closing. (There may be other changes in the future that affect this issues, but this ticket on its own can be handled currently via the marker.)