Tracking Issue for `#![feature(downcast_unchecked)]`

[ibraheemdev]

Feature gate: #![feature(downcast_unchecked)]

This is a tracking issue for the downcast_unchecked, downcast_ref_unchecked, and downcast_mut_unchecked methods.

Public API

impl dyn Any (+ Send + Sync) {
    pub unsafe fn downcast_ref_unchecked<T: Any>(&self) -> &T;
    pub unsafe fn downcast_mut_unchecked<T: Any>(&mut self) -> &mut T;
}

impl<A: Allocator> Box<dyn Any (+ Send + Sync), A> {
    pub unsafe fn downcast_unchecked<T: Any>(&self) -> Box<T, A>;
}

Steps / History

• Implementation: Add unchecked downcast methods #90851
• Final comment period (FCP)
• Stabilization PR

Unresolved Questions

• None yet.

[david-perez]

Should these be added to std::error::Error too?

[ibraheemdev]

I don't see how that would be useful. You generally don't know the concrete type of an error before downcasting.

[lunabunn]

This would allow me to shed my dependency on unsafe_any. What's the state of this feature? Is it ready for an FCP?

[ibraheemdev]

Now that {Option, Result}::unwrap_unchecked are stabilized, I wonder if there is much benefit to these methods.

[CAD97]

Instead of downcast_unchecked, is there a good reason to not just have the more general

impl Box<T: ?Sized, A> {
    pub unsafe fn cast_unchecked<U>(self) -> Box<U, A> {
        debug_assert_eq!(Layout::for_value(&*self), Layout::new::<U>());
        unsafe {
            let (raw, alloc) = Box::into_raw_with_allocator(self);
            Box::from_raw_in(raw.cast(), alloc)
        }
    }
}

? I suppose you lose the debug_assert! for correct typing which is possible if you have dyn Any, though it is true that you can already any.downcast().unwrap_unchecked() for that.

To immediately answer my own question: Box doesn't want to add methods to arbitrary types like that. cast_unchecked is still useful but would probably instead be pub unsafe fn Box::<T: ?Sized, A>::cast<U>(this: Self) -> Box<U, A> to make it an associated function rather than a method which could shadow a pointee's method.

[yshui]

@ibraheemdev this still generates better code than downcast_ref().unwrap_unchecked().

pub fn cast(a: &dyn std::any::Any) -> &i32 {
    unsafe { a.downcast_ref_unchecked() }
}

compiles to

example::cast:
        mov     rax, rdi
        ret

whereas

pub fn cast(a: &dyn std::any::Any) -> &i32 {
    unsafe { a.downcast_ref().unwrap_unchecked() }
}

becomes

example::xx:
        push    rbx
        mov     rbx, rdi
        call    qword ptr [rsi + 24]
        mov     rax, rbx
        pop     rbx
        ret

Both compiled with opt-level=3

[yshui]

I think llvm didn't realize that T::type_id call is pure (because it's called through the vtable?), so it kept the call.

[yshui]

huh, why is type_id not stored directly in the vtable?

[CAD97]

huh, why is type_id not stored directly in the vtable?

The short version is that Rust doesn't have a way to get associated constant data from a trait object (yet).

[gh2o]

The semantics of a.downcast_ref_unchecked() and a.downcast_ref().unwrap_unchecked() are still different. For example, with a.downcast_ref_unchecked() one could "transmute" between two types that are different but #[repr(C)] compatible in layout, whereas with a.downcast_ref().unwrap_unchecked() you'd likely be dereferencing a null pointer.