Tracking Issue for try_as_dyn

[ivarflakstad]

View all comments

Feature gate: #![feature(try_as_dyn)]

This is a tracking issue for the try_as_dyn and try_as_dyn_mut functions.

This feature will let us try to turn any value into a dyn MyTrait. If the value does not implement MyTrait then we simply return None so that the user can have some default functionality happen instead.

We expect to be able to remove many cases of specialization from the compiler and instead perform this kind of downcasting in the bodies of functions that were relying on specialization before.

A simple example could be

// Look ma, no `T: Debug`
fn downcast_debug_format<T: 'static>(t: &T) -> String {
    match std::any::try_as_dyn::<_, dyn Debug>(t) {
        Some(d) => format!("{d:?}"),
        None => "default".to_string()
    }
}

Public API

pub const fn try_as_dyn<
    T: Any + 'static,
    U: ptr::Pointee<Metadata = ptr::DynMetadata<U>> + ?Sized + 'static,
>(
    t: &T,
) -> Option<&U>

pub const fn try_as_dyn_mut<
    T: Any + 'static,
    U: ptr::Pointee<Metadata = ptr::DynMetadata<U>> + ?Sized + 'static,
>(
    t: &mut T,
) -> Option<&mut U>

Steps / History

(Remember to update the S-tracking-* label when checking boxes.)

• Implementation: Add try_as_dyn and try_as_dyn_mut #150033
• Remove 'static requirement (see https://rust-lang.zulipchat.com/#narrow/channel/144729-t-types/topic/solver.20mode.20for.20downcast_trait/with/560560270)
• support dyn trait again (for itself and for super trait)
• Final comment period (FCP)¹
• Stabilization PR

Unresolved Questions

• Where should these functions live?
  Currently the implementations are in the any module, which can be very confusing as these downcast concepts are for statically known types, while the downcast concepts in Any proper are for dynamic runtime types.
• try_as_dyn can observe whether a type hidden behind a RPIT implements a trait or not. This makes the opaque/hiding part of opaque types useless. This is hard to avoid because const eval generally reveals opaque types to get layout information
• Should we have a separate try_as_dyn_static that has a 'static bound and permits turning e.g. a &&'static str into a &dyn Trait even if there is an impl Trait for &'static str, and not a general impl?

Footnotes

1. https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html ↩

[Jules-Bertholet]

Going from a concrete type to a trait object is an upcast, not a downcast. I would suggest the names try_upcast/try_upcast_mut.

[ivarflakstad]

Going from a concrete type to a trait object is an upcast, not a downcast.

Oh yeah I think you're right hehe

Both upcast and downcast make more sense in OOP imo, where you typically have real inheritance like Cat: Animal and move up and down in levels of abstraction.
Since rust is more oriented toward capturing behaviour with traits (not up or down but more like sideways) maybe it should simply be trait_cast or something like that?
We have already started using downcast in any for runtime casts though, so perhaps best to just stick to the established terminology and use upcast.

[oli-obk]

Other APIs suggest this would be more a try_as_trait or sth like that. No mentioning of down or up ast, just naming it for its intended use case

[camsteffen]

try_as_dyn or as_dyn or as_dyn_trait? The try_ seems not really necessary if there is no non-try version. The _trait seems over-simplified since IIUC you might have something like dyn Trait + Sync. So I think std::convert::as_dyn is good?

[izagawd]

We would probably need to edit this tracking issue to align with the new name (try_as_dyn) and implementation.

[axos88]

Awesome work, this really fills a gap. But the current implementation misses the case when an instance cannot be specified, such as:

trait TypeHasUuid { 
  fn type_id() -> String;
}

impl TypeHasUuid for u32 { 
  fn type_id() -> { return "550e8400-e29b-41d4-a716-446655440000".to_string(); }
}

fn get_type_id<T>() -> String {
        #[cfg(feature = "has-try-as-dyn")]
        {
            if let Some(id) = core::any::try_as_dyn::<T, dyn TypeHasUuId>(??????) {    /// <<<<-----
                return id.type_id().to_string();
            }
        }

        // Fallback implementation using std::any::type_name
      std::any::type_name::<T>().to_string()
}

I'd love to be able to write something like

fn get_type_id<T>() -> String {
        #[cfg(feature = "has-try-as-dyn")]
        {
            if implements<T, TypeHasUuid> {   
                return <T as TypeHasUuid>::type_id();
            }
        }

        // Fallback implementation using std::any::type_name
      std::any::type_name::<T>().to_string()
}

[danielhenrymantilla]

@axos88, you'd do the something like the following:

trait TypeUuid { 
    fn type_uuid() -> String;
}

fn get_type_uuid<T>() -> Option<String> {
    use ::core::marker::PhantomData;

    trait PhantomTypeUuid {
        fn type_uuid(&self) -> String;
    }

    impl<T: TypeUuid> PhantomTypeUuid for PhantomData<T> {
        fn type_uuid(&self) -> String { T::type_uuid() }
    }
    
    #[cfg(feature = "has-try-as-dyn")]
    {
        if let Some(dyn_wit) = PhantomData::<T>.try_as_dyn::<_, dyn PhantomTypeUuid>() {
            return Some(dyn_wit.type_uuid());
        }
    }

    None
}

[axos88]

Thats pretty clever, haha. Ill try it.