Repository navigation
try_as_dyn does not work with builtin impls #162134
Description
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.
Activity
maxdexh commentedon Sep 1, 2026
Note that the
SyncAbleimpl isn't builtin, but theimpl Sync for u32is. Builtin impls get ignored, even if you obscure them through a blanket impl like here. This is consistent withCopysince theCopyimpl is not builtin.simpler example to show this:
BoxyUwU commentedon Sep 2, 2026
cc @oli-obk
theemathas commentedon Sep 2, 2026
The reason try_as_dyn doesn't work with builtin impls was: I discovered that the builtin impl that makes
dyn TraitimplementTraitcan 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 commentedon Sep 2, 2026
Its not inconsistent regarding builtin impls in general. But its inconsistent for a certain traits: Sometimes a
Copyis 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.