UnsafeCell should implement the Copy trait

[diwic]

Currently UnsafeCell does not implement Copy. It would be beneficial if it could, for at least two reasons:

• Easier initialization of fixed arrays, e g: [UnsafeCell::new(0i32); 75]
• It enables people to make cell-like types which are Copy.

AFAIK, there are no disadvantages for UnsafeCell to implement Copy.

Note: the reason people can't just copy-and-paste the code for UnsafeCell to make their own variant with copy semantics, is that UnsafeCell is a #[lang="unsafe_cell"]: "The UnsafeCell<T> type is the only legal way to obtain aliasable data that is considered mutable. In general, transmuting an &T type into an &mut T is considered undefined behavior."

[mattico]

This seems like it would require an RFC:
Any semantic or syntactic change to the language that is not a bugfix.
https://github.com/rust-lang/rfcs

[ftxqxd]

@mattico Making UnsafeCell implement Copy isn’t a change to the language, it’s a change to the standard library. The rules for what requires an RFC aren’t very clear, anyway.

[reem]

If adding a trait impl to a type required an RFC we would never get anything done.

[alexcrichton]

There is currently no stable and safe method to read the value in an UnsafeCell, and this is intentional. There is no knowledge about concurrent reads/writes/etc with an UnsafeCell, and introducing an unsynchronized read with an implicit Copy may produce undefined behavior in some situations.

[diwic]

@alexcrichton UnsafeCell is a building block for higher level abstractions, e g Cell, RefCell and AtomicUsize. This higher level abstraction determines whether unsynchronized reads are possible or not, by optionally deriving Copy (and/or Send/Sync) themselves. (Or by adding NoCopy markers.)
If UnsafeCell implements Copy, then the higher level abstractions are free to make this choice. The current situation makes this impossible.

Could you be more specific about the "undefined behavior in some situations"? And is this a problem with UnsafeCell in itself, or something that can be easily fixed in the type containing the UnsafeCell?

[alexcrichton]

Yes each type which contains an UnsafeCell could also take on deciding these kinds of decisions, there's no absolutely fundamental reason why it does not implement Copy.

[diwic]

I was thinking about this again today and I'm wondering if it would be better to remove the unsafe_cell lang_item and instead introduce a new marker, e g AliasedMutRef or so, that would mean essentially the same (disable the assumption/optimisation that two mutable references can never refer to the same object)?

Then people could implement their own cells with what ever degree of unsafety they want.

[nox]

We need this for FFI with C and C++ too, where it would be nice to be able to tell that some struct fields may change through unknown means.

[arielb1]

+1

[aturon]

Nominating for libs team discussion.

[alexcrichton]

This libs team discussed this issue a few days ago and we unfortunately didn't reach a firm consensus. The case I mentioned above means that guaranteeing the safety of an unsafe block with an UnsafeCell would not also entail auditing all copies in addition to accesses. This does, however, somewhat align with the desire for safe methods like get_mut (to get a &mut T reference).

One idea brought up by @sfackler was perhaps something like unsafe impl Copy for T {} where the type T is then copyable regardless of contents (but is clearly unsafe, hence the requirement of unsafe). This idea hasn't been played out too much, though, and would certainly require an RFC.

One other concern here is that if UnsafeCell implements Copy that it would also necessitate an implementation of Clone, which may be more dubious.