8
Downcasting Arcs in Rust
(ashdnazg.github.io)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 06 Aug 2026
8 points (100.0% liked)
Rust
8204 readers
6 users here now
Welcome to the Rust community! This is a place to discuss about the Rust programming language.
Wormhole
Credits
- The icon is a modified version of the official rust logo (changing the colors to a gradient and black background)
founded 3 years ago
MODERATORS
While interesting, this entire article works with a static
MyStruct. This means the type already isAny, and if you defineMyTrait: 'static, then you can do the downcast by first casting to anArc<dyn Any>and using one of the downcast methods.For non-
'statictypes, downcasting soundly is incredibly difficult. You need to somehow get the correct lifetime back from the trait. You're better off usingunsafeat that point anyway. If the trait itself holds the lifetime (impl<'a> MyTrait<'a> for MyStruct<'a>), then that can help with it, though I'm not really sure how lifetime variance plays into the soundness of a downcast here.Finally, at the end, I'd rather just use an
assert!over an unchecked assertion. I know the goal is to look at the assembly with that assertion in place, so it makes sense why they used it here. In practice, an actual assertion is a lot better because the compiler gets the same information from it and you get validation at runtime that the information is correct.Anyway, great article! The goal was to explore how
Arccasting works, and I think it does a great job at showing and explaining that.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?