Stable type identifiers: a missing piece for crABI and export

ParaDevOne:

Lifetimes, Higher-Ranked Type Constraints, and Dyn Types. Up until now, I wasn't aware of the numerous limitations concerning the TypeId. If TypeId has the same restrictions in this proposal, that is a substantial limitation. Would it be possible for you to supply me with some information so that I can gain an understanding of what allows and/or limits me with respect to these restrictions?

For higher ranked types, you need a way to distinguish between e.g.

fn(&str) // aka for<'a> fn(&'a str)
fn(&'static str)

In addition to fn pointers, dyn types can also be higher-ranked (dyn for<'a> Trait<'a>).

For dyn Trait types, you need to decide what their "path" or other unique identifier is (based on the trait, presumably). Then you need to account for every possible dyn Trait + Send, + Sync, + Send + Sync combination somehow. Another detail is that associated types with Sized bounds may or may not be specified.

TypeId does handle the above issues, but it's limited to types which meet a 'static bound. Perhaps this closed tracking issue is a good place to start learning about that limitation. (TypeId also has hashing concerns, but AFAIU they are solvable via changing implementation details.)

All that being said, I personally suspect "it's now a breaking change to move your struct and trait declarations around" is a blocker for the path based concept.