-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Tracking Issue for SyncUnsafeCell #95439
Comments
The arguments in favor of having such a type are contained in the (very long) thread at #53639 . TL;DR: |
This would be a great addition to the standard library. Most OS-level crates I've worked on eventually have to use This abstractions makes it so raw pointer math would be safe, while use of the pointee to would be unsafe. A concrete example is from @phil-opp's blog "Writing an OS in Rust" where |
I think the former might be the best, if it's unconditionally |
Conceptually, I think In practice, I commonly deal with types containing raw pointers (coming from bindgen), which are (very un-ergonomically) |
There has been previous discussion that if a new In particular, it seems as though stabilizing this without a As background: @SimonSapin proposed this primitive here: #55207 (comment) #53639 (comment) @aturon discussed adding a separate @RalfJung analyzed the situation in some detail: #25053 (comment) #55207 (comment) Footnotes
|
In general, in my uses of UnsafeCell-made-sync, which are typically data structures that I am managing thread safety manually, e.g. for thread safe queues or allocators or such, I very much would not want it to be I'm not certain if the proposal was something like: impl<T: Copy> Copy for NewUnsafeCell<T> {} Which might be more palatable, but it would probably make me nervous that I might ACCIDENTALLY make my types copy, when I really don't want them to be, for example if I happened to use some I think a lot of mine (and maybe others?) desire for a const SINGLE: UnsafeCell<NonCopyType> = UnsafeCell::new(NonCopyType::const_new());
let arr: [UnsafeCell<NonCopyType>; 64] = [SINGLE; 64]; There might be others who have that desire! But you pinged me, and I can't say I've ever wanted it, outside of initializers, where the "Const Single" pattern works reasonably well, even if it isn't completely widely known. Edit: As a very quick example, I feel like it would be a footgun to make this structure |
It looks like I did write a few years ago about a possible
|
Oh. I just now realized I opened #55207 in 2018, which proposed to make UnsafeCell Copy/Clone (oh how time flies!) As I mentioned downthread: #55207 (comment), I definitely agree that my original goal was mainly around const/array initialization, which is solved by (better IMO) by #49147. |
That would not happen. You still have to add I really don't understand the problem here. |
In the example I gave, Therefore without adding |
I assumed you were talking about a type you defined yourself. Interior mutability data stores can be perfectly fine with |
That's fair. However some of my worst bugs when working with unsafe are when I accidentally create a copy of some data that happens to be Copy (e.g. accidentally copying to the stack when trying to reborrow from a pointer), then returning a reference to a local rather than the non-local pointer. Since UnsafeCell is likely to be used in pointer form (e.g. through the This is probably a niche issue (and almost certainly only a personal experience report), but that's my $0.02. If there are other compelling use cases, I'll just have to be more careful in the future, or stick with the old |
I think this is a really important point. I think this is case where Rust accidentally mixes 'unsafe' with 'just a bad idea'. The best example of that is how At this point we can't just make these types |
It reminds me also of some arguments for whether to implement |
I support this, although I think it should be explicitly marked as a " |
It's not really a static mut killer as is, since it doesn't relax the Send requirement. When I've wanted to use it this has been an issue (since we have a few types which are !Send & !Sync just as lints). I do see why this limitation exists, though. |
Would it be better to have a generic |
I would appreciate having something like this. Creating static structs for things like plugins is really quite painful, especially when they contain raw pointers, because you have to wrap everything in a sync-forcing type (e.g. from one of my proc macros, my I don't think an Question just since I haven't seen it anywhere - is |
Some existing unsafe code might rely on the auto-trait behavior of For example, |
Another option which I don't see mentioned here is making |
While I understand the concerns, this is mostly a matter of discipline and letting the compiler figuring out the necessary reborrowing. Since an To show a use of having a #[derive(Clone, Copy)]
struct Foo<T> { ... }
impl<T> Foo<T> {
fn operate(&self); // note *NOT* &mut self. All operations are sequenced in the backend.
} So I would want to increase the counter in EDIT: Tl;dr Thinking and reading more about this, I believe that not having a |
Feature gate:
#![feature(sync_unsafe_cell)]
This is a tracking issue for SyncUnsafeCell.
Public API
Steps / History
Unresolved Questions
Sync
only ifT
isSync
, or should it unconditionally beSync
?The text was updated successfully, but these errors were encountered: