# Specialization for better Debug for Any

**URL:** <https://internals.rust-lang.org/t/specialization-for-better-debug-for-any/4029>\
**Category:** libs\
**Created:** [September 7, 2016, 10:22pm UTC](https://internals.rust-lang.org/t/specialization-for-better-debug-for-any/4029 "2016-09-07T22:22:02Z")\
**Posts on this page:** 1\
**Showing post:** 4

<div class="post-metadata">

**Author:** ![eddyb](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/eddyb/32/8411_2.png) [@eddyb](https://internals.rust-lang.org/u/eddyb)\
**Post date:** [September 8, 2016, 5:21am UTC](https://internals.rust-lang.org/t/specialization-for-better-debug-for-any/4029/4 "2016-09-08T05:21:31Z")

</div>

Not sure what the relationship with thin object pointers is.

There’s [a contraption I did two years ago](https://gist.github.com/eddyb/f828f8ce819a5f00d42d) and @Diggsey [has a brand new independent implementation](https://www.reddit.com/r/rust/comments/514i1r/query_interface_easier_runtime_polymorphism_in/) and the only requirement is listing all the traits you want to expose ahead of time.

Removing that requirement ends up with polymorphic and cross-crate concerns, besides needing compiler support.

If you only generate the RTTI information only in executable crates then the cross-crate concern more or less go away and you can get all the monomorphic trait impls.

Polymorphic trait RTTI requires a much more complex system that can reflect on structural types and polymorphic nominal types (i.e. the whole typesystem) and effectively do trait `impl` selection at runtime.

It’s doable (Haskell and Julia are relevant examples, I believe), and Rust could do it without garbage collection, but it would be a lot of work for a slow system (if you don’t also throw a JIT in, which is even more work).

---

_[View the full topic](https://internals.rust-lang.org/t/specialization-for-better-debug-for-any/4029)._