`try_as_dyn` does not work with builtin impls

[Janrupf]

Lifting this from a discussion on Zulip.

core::any::try_as_dyn doesn't work (always returns None) when trying to access builtin impls in any way:

trait SyncAble {}
impl<T> SyncAble for T where T: Sync /* <- builtin */ {}

println!("{}", core::any::try_as_dyn::<u32, dyn SyncAble>(&0).is_some());

Thats quite annoying because checking whether T: Sync holds would potentially allow for optimizations (offloading computations). The same applies to all other builtin impl's. This can be quite confusing, especially because its not consistent for a single trait either.

[maxdexh]

Note that the SyncAble impl isn't builtin, but the impl Sync for u32 is. Builtin impls get ignored, even if you obscure them through a blanket impl like here. This is consistent with Copy since the Copy impl is not builtin.

simpler example to show this:

let _: &dyn Send = try_as_dyn(&1).unwrap(); // doesn't work

[BoxyUwU]

cc @oli-obk

[theemathas]

The reason try_as_dyn doesn't work with builtin impls was: I discovered that the builtin impl that makes dyn Trait implement Trait can be lifetime-dependent (#150161 (comment)). Oli decided to fix this by blanket-banning all builtin impls.

This ban is probably broader than it needs to be, but it's not clear if there's a more principled fix, other than maybe allowing individual builtin impls one by one.

Could you explain what you think is inconsistent with the current treatment of builtin impls?

[Janrupf]

Its not inconsistent regarding builtin impls in general. But its inconsistent for a certain traits: Sometimes a Copy is not builtin, sometimes it is for example. This requires the user to understand when something is possibly a builtin impl. My expectation would be that it at least always works for a certain trait or doesn't.

I believe the correct fix would be to not ignore builtin impls in general, but ignore the non-'static ones.