Suggestion to use Arc<T> is too indiscriminate

[dtolnay]

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:1

Desired output

No response

Rationale and extra context

Filing to track the hesitation from #88936 (review).

[@nagisa]— Use of Arc is not always applicable, as both Send and Sync impls for Arc<T> require T: Send + Sync. Unless we can verify T bounds here, I don't think this on clause adds any more clarity over the default note?

[@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

[dtolnay]

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 like Arc<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 an Arc could be incorporated to share this value between threads" would be most appropriate.

[reez12g]

@rustbot claim

[m-ou-se]

Suggesting Arc<T> for missing Send or Sync on T is always wrong. Arc<T> is never Send or Sync when T isn't. This message shouldn't be tweaked or changed to appear in fewer cases, but just removed.

An Arc is 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.)