Repository navigation
Suggestion to use Arc<T> is too indiscriminate #114687
Description
Code
fn main() {
let ptr = &false as *const bool;
std::thread::spawn(move || println!("{:p}", ptr)).join().unwrap();
}Current output
error[E0277]: `*const bool` cannot be sent between threads safely
--> src/main.rs:4:24
|
4 | std::thread::spawn(move || println!("{:p}", ptr)).join().unwrap();
| ------------------ -------^^^^^^^^^^^^^^^^^^^^^^
| | |
| | `*const bool` cannot be sent between threads safely
| | within this `[closure@src/main.rs:4:24: 4:31]`
| required by a bound introduced by this call
|
= help: within `[closure@src/main.rs:4:24: 4:31]`, the trait `Send` is not implemented for `*const bool`
= note: consider using `std::sync::Arc<*const bool>`; for more information visit <https://doc.rust-lang.org/book/ch16-03-shared-state.html>
note: required because it's used within this closure
--> src/main.rs:4:24
|
4 | std::thread::spawn(move || println!("{:p}", ptr)).join().unwrap();
| ^^^^^^^
note: required by a bound in `spawn`
--> /rustc/08d00b40aef2017fe6dba3ff7d6476efa0c10888/library/std/src/thread/mod.rs:680:1Desired output
No response
Rationale and extra context
Filing to track the hesitation from #88936 (review).
[@nagisa]— Use of
Arcis not always applicable, as bothSendandSyncimpls forArc<T>requireT: Send + Sync. Unless we can verifyTbounds here, I don't think thisonclause adds any more clarity over the defaultnote?
[@estebank]— Thats fair, but was concerned the default would be too verbose for a case where we could be more straightforward. I can change it.
[@nagisa]— Well, we can always change this later too. r=me if you don't want to change it.
If T is not Send then Arc<T> is also not Send. Suggesting Arc<T> whenever Send is not implemented seems misguided.
Other cases
No response
Anything else?
No response
Reacted by Mateusz Mikuła and Mara Bos
Activity
dtolnay commentedon Aug 10, 2023
The link to https://doc.rust-lang.org/book/ch16-03-shared-state.html is a good addition and will be valuable for beginners. 💯
I think concretely the unhelpfulness is in regard to
Arc<{Self}>which is (almost?) never going to be right. Something likeArc<Mutex<{Self}>>is more likely to be the right "silver bullet". I'd prefer not to suggest even that though. I think guiding toward the link and contextualizing with something like "consider whether anArccould be incorporated to share this value between threads" would be most appropriate.reez12g commentedon Aug 12, 2023
@rustbot claim
m-ou-se commentedon Aug 23, 2023
Suggesting
Arc<T>for missingSendorSynconTis always wrong.Arc<T>is neverSendorSyncwhenTisn't. This message shouldn't be tweaked or changed to appear in fewer cases, but just removed.An
Arcis a tool to fix/avoid lifetimes, not for making anything Send or Sync. (A Mutex can make a Send-but-not-Sync thing Sync, but that also doesn't make a non-Send thing Send.)Rollup merge of rust-lang#115311 - dtolnay:usearcself, r=compiler-errors