{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreifduz5ufn7xoppa3ngiia7pd4jkllxq6codxithxnjhrrfavafx7q",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mitkifipm7v2"
  },
  "path": "/t/stable-type-identifiers-a-missing-piece-for-crabi-and-export/24093?page=2#post_38",
  "publishedAt": "2026-04-05T18:18:27.000Z",
  "site": "https://internals.rust-lang.org",
  "tags": [
    "[1]",
    "[2]",
    "[3]",
    "[4]",
    "↩︎"
  ],
  "textContent": "You've asserted that stable type names (or _some_ form of identifier) is desirable, but as far as I can tell, you've failed to identify _why_. What exactly are the use cases, why do they only care about type identity and not structure/ABI, and why aren't they served by existing solutions?\n\nPeople have identified potential flaws in the initial idea, but without semi-concrete use cases that we can evaluate the solution against, it's difficult for anyone to identify whether those are blocking or a non-issue (or even a desirable limitation).\n\nThe closest to a concrete application I was able to determine[1] was for (de)serialization, especially in a bevy ECS like serialized `List<dyn Any>` scenario.\n\nFor typical serde-like serialization schemes, the type name alone is enough (or even more than enough), as type context informs what the possibilities are. It doesn't matter if `Left` is ambiguous, because in the context of deserializing the specific container type you already know it must be `Either::<T, U>::Left`. This is what allows highly contextual an non-self-describing binary formats to work at all.\n\nIn the case of a heterogenous collection, things get more complicated, which is why serde can't support deserializing `dyn Trait` out of the box. What _can_ be done is collecting a list of every `impl Trait` that you potentially care about[2], and then essentially deserializing a fake `enum Everything` with variants for every implementor.\n\nBevy _very specifically_ wants legible names for their textual scene format, so 128bit or 256bit hashes are not a great option for them. For formats that aren't meant to be human readable, though, an opaque but stable type identifier would mean this strategy won't run into name collisions! ...Except you still need to deal with renames, potentially even cross-crate renames[3], and you need to annotate/register your types somewhere, so you might as well assign a `#[track_caller]` `Location`[4] based identity by default and allow specifying a user defined id for cases that need stability in the face of `Location` changing refactora.\n\n* * *\n\n  1. \"For plugins\" isn't very specific, and any usages I can come up with don't need name stability between versions without also needing ABI compatibility info or just simplifying to the (de) serialization case. ↩︎\n\n  2. Either via explicit registration like bevy-reflect, or implicitly like typetag. ↩︎\n\n  3. E.g. extracting a type into a lib-core crate so it's still the same type between lib@1 and lib@2. ↩︎\n\n  4. It's not currently possible to construct `Location` except via the panic machinery. I'd be weakly in support of extending that capability to user code alongside appropriate warnings about stability and appropriate usage like exists on `any::type_name` and other for-debug-usage APIs. ↩︎\n\n\n",
  "title": "Stable type identifiers: a missing piece for crABI and export"
}