Skip to content

UnsafeCell should implement the Copy trait #25053

Not planned
@diwic

Description

@diwic
Contributor

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

Activity

mattico

mattico commented on May 2, 2015

@mattico
Contributor

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

ftxqxd commented on May 2, 2015

@ftxqxd
Contributor

@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

reem commented on May 3, 2015

@reem
Contributor

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

alexcrichton

alexcrichton commented on May 3, 2015

@alexcrichton
Member

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

diwic commented on May 3, 2015

@diwic
ContributorAuthor

@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

alexcrichton commented on May 4, 2015

@alexcrichton
Member

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

diwic commented on Jun 2, 2015

@diwic
ContributorAuthor

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

nox commented on May 5, 2016

@nox
Contributor

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

arielb1 commented on May 5, 2016

@arielb1
Contributor

+1

added
T-libs-apiRelevant to the library API team, which will review and decide on the PR/issue.
on May 5, 2016
aturon

aturon commented on May 5, 2016

@aturon
Member

Nominating for libs team discussion.

alexcrichton

alexcrichton commented on May 11, 2016

@alexcrichton
Member

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.

65 remaining items

Loading
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    C-feature-requestCategory: A feature request, i.e: not implemented / a PR.T-langRelevant to the language teamT-libs-apiRelevant to the library API team, which will review and decide on the PR/issue.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @steveklabnik@comex@alexcrichton@eddyb@nox

        Issue actions

          UnsafeCell should implement the Copy trait · Issue #25053 · rust-lang/rust