{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreib6nzqoxlffucm2c4lwzko3iwzyrmmr22lr2km7z6a2ecs5efov3m",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mhet3nmze6t2"
  },
  "path": "/t/stable-type-identifiers-a-missing-piece-for-crabi-and-export/24093#post_16",
  "publishedAt": "2026-03-18T18:20:18.000Z",
  "site": "https://internals.rust-lang.org",
  "tags": [
    "this closed tracking issue",
    "also has hashing concerns,"
  ],
  "textContent": "ParaDevOne:\n\n> 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?\n\nFor higher ranked types, you need a way to distinguish between e.g.\n\n\n    fn(&str) // aka for<'a> fn(&'a str)\n    fn(&'static str)\n\n\nIn addition to `fn` pointers, `dyn` types can also be higher-ranked (`dyn for<'a> Trait<'a>`).\n\nFor `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.\n\n`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.)\n\n* * *\n\nAll 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.",
  "title": "Stable type identifiers: a missing piece for crABI and export"
}