ACP: Add allocation-free owned downcasting for Any values

Proposal

Problem statement

Add a safe, allocation-free API for checked owned downcasting between generic Any values.

The core operation would be equivalent to:

use std::any::Any;

fn downcast<T: Any, U: Any>(value: T) -> Result<U, T>;

Motivating examples or use cases

Currently, this can be done by:

fn downcast<T: Any, U: Any>(value: T) -> Result<U, T> {
    match (Box::new(value) as Box<dyn Any>).downcast::<U>() {
        Ok(value) => Ok(*value),
        Err(other) => {
            let value = other.downcast::<T>().unwrap();
            Err(*value)
        }
    }
}

But it would introduce a Box allocation unconditionally.

I have a real-world use case in https://github.com/fast/traversable/pull/22#discussion_r3349184549 that would benefit from such an API. And since Box<dyn Any> can be downcast, a similar struct off heap should be able to do so as well.

Solution sketch

The exact API shape is open to bikeshedding. Some possible designs are as below:

// top-level function
fn downcast<T: Any, U: Any>(value: T) -> Result<U, T> {
    if TypeId::of::<T>() == TypeId::of::<U>() {
        Ok(unsafe { transmute_neo(value) })
    } else {
        Err(value)
    }
}

// method on Any

pub trait Any: 'static {
    // ...

    // no need for T: Any; could be this: Self instead of self if desired
    fn downcast_move<T: 'static>(self) -> Result<T, Self>
    where
        Self: Sized,
    {
        if TypeId::of::<Self>() == TypeId::of::<T>() {
            Ok(unsafe { transmute_copy(&ManuallyDrop::new(self)) })
        } else {
            Err(self)
        }
    }
}

Alternatives

N/A

Links and related work

What happens now?

This issue contains an API change proposal (or ACP) and is part of the libs-api team feature lifecycle. Once this issue is filed, the libs-api team will review open proposals as capability becomes available. Current response times do not have a clear estimate, but may be up to several months.

Possible responses

The libs team may respond in various different ways. First, the team will consider the problem (this doesn't require any concrete solution or alternatives to have been proposed):

• We think this problem seems worth solving, and the standard library might be the right place to solve it.
• We think that this probably doesn't belong in the standard library.

Second, if there's a concrete solution:

• We think this specific solution looks roughly right, approved, you or someone else should implement this. (Further review will still happen on the subsequent implementation PR.)
• We're not sure this is the right solution, and the alternatives or other materials don't give us enough information to be sure about that. Here are some questions we have that aren't answered, or rough ideas about alternatives we'd want to see discussed.

Start by reviewing the proposal, its motivating traversable pull request discussion, and the existing Box::downcast behavior described in the issue. Compare the proposed API shapes and safety constraints, then follow the libs-api feature lifecycle; done means the team has resolved whether the problem and a concrete standard-library API should proceed.