9
The Arc type is Rust’s thread-safe smart pointer, and like other pointer types in Rust (e.g., Box), one can use the as keyword1 to cast an Arc into an Arc, as long as MyTrait is dyn compatible. What about casting it back from Arc to Arc? Well, here the plot thickens a bit. We can’t use the as keyword here, because that operation is inherently unsafe. An arbitrary Arc might not hold a MyStruct in it, but some other object that implements MyTrait, and trying to cast it into the wrong type would result in undefined behaviour. But the fact that something is unsafe doesn’t mean it should be impossible, or even undesirable. An unsized coercion if you want the fancy term. ↩


Is it?
I didn’t read past the first sentence:
This is horrible in my view. All types that implement
Derefand/orDerefMutcan be called smart pointers, and everything is “thread-safe” in safe Rust.If I had to call something “Rust’s thread-safe smart pointer”, it would be the actual references
&T/&mut TwhereT: Send + Sync.Digression: All the traits involved like the 4 mentioned above point to the C++ centric concept of smart pointer not mapping cleanly to Rust semantics imho. But that’s a long lost battle.
Let’s see what the official
Arcdocs say:Will you look at that! An actually accurate short description that is already available.
While not widespread, there is already a small myth out there that paints Rust as if it’s Swift-like, a ref-counting centric language.
This is a very pedantic complaint. Given that you haven’t read past the first sentence, I’m not really sure what to discuss here.
“Smart pointer” is commonly used to refer to reference-counted pointers that free automatically.
Not everything is thread-safe in safe rust; while safe rust prevents you from using thread-unsafe constructs in a threaded context, most types are not thread-safe. That’s why you have both
RcandArc, since it is not safe to use non-atomic reference counting in a threaded context, but you don’t need the overhead of atomics in a non-threaded context.Nor are
references &T/&mut T where T: Send + Syncconsidered smart pointers in Rust. Those are just references to something that itself implements the traits required to make that type thread-safe.See also https://doc.rust-lang.org/stable/book/ch15-00-smart-pointers.html and https://doc.rust-lang.org/std/sync/struct.Arc.html#thread-safety
Safe rust is thread-safe in the sense that you can’t have runtime thread unsafely. If we are going to ignore the role of compile-time errors, then literally nothing is safe.
Also, what is “most”? Can you source that claim?