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. ↩
  • TehPers@beehaw.orgEnglish
    4·
    20 days ago

    While interesting, this entire article works with a static MyStruct. This means the type already is Any, and if you define MyTrait: 'static, then you can do the downcast by first casting to an Arc<dyn Any> and using one of the downcast methods.

    For non-'static types, downcasting soundly is incredibly difficult. You need to somehow get the correct lifetime back from the trait. You’re better off using unsafe at 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 Arc casting works, and I think it does a great job at showing and explaining that.

    • BB_C@programming.dev
      2·
      19 days ago

      great article!

      Is it?

      I didn’t read past the first sentence:

      The Arc type is Rust’s thread-safe smart pointer

      This is horrible in my view. All types that implement Deref and/or DerefMut can 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 T where T: 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 Arc docs say:

      A thread-safe reference-counting pointer.

      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.

      • TehPers@beehaw.orgEnglish
        6·
        19 days ago

        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.

      • fruitcantfly@programming.dev
        4·
        19 days ago

        This is horrible in my view. All types that implement Deref and/or DerefMut can 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 T where T: Send + Sync.

        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 Rc and Arc, 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 + Sync considered 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

        • BB_C@programming.dev
          1·
          19 days ago

          most types are not thread-safe.

          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?