Not planned
Description
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."
Metadata
Metadata
Assignees
Labels
Type
Projects
Milestone
Relationships
Development
No branches or pull requests
Activity
mattico commentedon May 2, 2015
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 commentedon May 2, 2015
@mattico Making
UnsafeCell
implementCopy
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 commentedon May 3, 2015
If adding a trait impl to a type required an RFC we would never get anything done.
alexcrichton commentedon May 3, 2015
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 anUnsafeCell
, and introducing an unsynchronized read with an implicitCopy
may produce undefined behavior in some situations.diwic commentedon May 3, 2015
@alexcrichton
UnsafeCell
is a building block for higher level abstractions, e gCell
,RefCell
andAtomicUsize
. This higher level abstraction determines whether unsynchronized reads are possible or not, by optionally derivingCopy
(and/orSend
/Sync
) themselves. (Or by addingNoCopy
markers.)If
UnsafeCell
implementsCopy
, 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 theUnsafeCell
?alexcrichton commentedon May 4, 2015
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 implementCopy
.diwic commentedon Jun 2, 2015
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 gAliasedMutRef
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 commentedon May 5, 2016
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 commentedon May 5, 2016
+1
aturon commentedon May 5, 2016
Nominating for libs team discussion.
alexcrichton commentedon May 11, 2016
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 anUnsafeCell
would not also entail auditing all copies in addition to accesses. This does, however, somewhat align with the desire for safe methods likeget_mut
(to get a&mut T
reference).One idea brought up by @sfackler was perhaps something like
unsafe impl Copy for T {}
where the typeT
is then copyable regardless of contents (but is clearly unsafe, hence the requirement ofunsafe
). This idea hasn't been played out too much, though, and would certainly require an RFC.One other concern here is that if
UnsafeCell
implementsCopy
that it would also necessitate an implementation ofClone
, which may be more dubious.65 remaining items