{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreiarafsaumnze7ouunifxozq6tuydmjk3bpemb2mnrfdxwlac2s4jq",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mhbutgs45b62"
  },
  "path": "/t/stable-type-identifiers-a-missing-piece-for-crabi-and-export/24093#post_1",
  "publishedAt": "2026-03-17T20:17:42.000Z",
  "site": "https://internals.rust-lang.org",
  "textContent": "# Rust Permanent/Stable Type Identifiers\n\nI have an idea related to #3435 and #3470 that differs from both of them.\n\n## The Idea\n\nThe idea is that Rust would add permanent identifiers for every type. These identifiers would be derived from the full path of a type, i.e., the identifier for `std::vec::Vec` would be derived from the path `std::vec::Vec` and not from the internal structure of `std::vec::Vec` or its memory footprint, only its path.\n\nThis permanent identifier would not change when you change your job or move homes, just as a national identification number does not change when you make those changes.\n\nFor example, the permanent identifier for Vec would be found by hashing the path of the type.\n\n\n    hash(\"std::vec::Vec\")                        → permanent identifier for `Vec`\n    hash(\"my_crate::MyType\")                     → permanent identifier for `MyType`\n    hash(\"std::vec::Vec\") + hash(\"i32\")        → permanent identifier for `Vec`\n\n\n## What This Is NOT\n\nThis is not a stable ABI: The memory layout of `Vec` can remain unstable while the identifier that is telling you that `Vec` is of type `i32` is stable. These two concepts exist at different layers.\n\nAlso, derived identifiers are not a derivation from the real structure of the type. For example, an identifying hash value of `Vec` does not change if the implementation of `Vec` changes.\n\n## How it Works\n\n  * The compiler will assign the hash based on the full path to the type, and it will do so deterministically. There will be no manual hash value assigned and no central authority to assign hashes.\n\n  * Generics are composable; that is to mean that the programmer will still write `Vec` as they have been doing, and from there the compiler will derive the permanent identifier.\n\n\n\n\n\n    hash(Vec)  = hash(\"std::vec::Vec\") + hash(\"i32\")\n    hash(Vec) = hash(\"std::vec::Vec\") + hash(\"std::string::String\")\n\n\nThe programmer does not need to do anything. It's perfectly see-through.\n\n**No collisions between crates:**\n\n\n    hash(\"my_crate::User\")  ≠ hash(\"other_crate::User\")\n\n\nPaths in Rust are always unique, by definition.\n\n**When does the hash change?** It only changes if how it was computed is changed explicitly. It is not affected by updates to rustc, assuming no changes were made. It is an explicit breaking change — similar to semver.\n\n## How it differs from #3435 and #3470\n\n  * **#3470 (crABI)** resolves issues regarding inter-language memory layout and representation, but does not provide a method of formally defining stable type identifiers.\n  * **#3435 (export)** deals with how to export symbol information dynamically. It requires stable identifiers, but also does not define them.\n  * **The proposal** presented in this document will provide the missing piece, which is an unambiguous, deterministic identifier for all types.\n\n\n\n### Importance\n\nThe use of stable type signatures is critical to having Rust-to-Rust dynamic linkage, as the absence of stable type information means that any dynamic linkage would require unsafe FFI in Rust, and it creates a major source of pain when building plugin systems. Additionally, crABI and export will have no foundation to work from for stable symbol (and possibly ABI) mangling. Therefore, the proposal presented here is the first concrete step toward establishing a stable ABI while not breaking anything in the present.\n\n### Outstanding Issues\n\nThe exact algorithm for combining generics having more than one type parameter is not yet resolved. Also unresolved is how `combine` interacts with types that have generics which are defaulted (such as `HashMap`).\n\nThis idea was raised here because I think it needs more technical evolution than I could do on my own. I am looking for input as to whether this direction has been investigated to date and, if so, what the status of that discussion is.",
  "title": "Stable type identifiers: a missing piece for crABI and export"
}