Tracking Issue for try_as_dyn

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: https://github.com/rust-lang/rust/pull/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)^1
• 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?

Start with the implementation linked as PR #150033 and the public entry points std::any::try_as_dyn and try_as_dyn_mut. Review the remaining checklist items and unresolved questions, including the 'static requirement, dyn-trait support, API location, and stabilization process; done means those design and lifecycle steps are resolved.