{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreiatf47gs2l4k54ya2wlzislsotgspnygbfvnsyfv7r3ogymo7r3ku",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3migwx7undho2"
  },
  "path": "/t/stable-type-identifiers-a-missing-piece-for-crabi-and-export/24093?page=2#post_25",
  "publishedAt": "2026-04-01T14:51:59.000Z",
  "site": "https://internals.rust-lang.org",
  "textContent": "The main use case I have in mind is plugins and dynamic Rust-to-Rust linking. In that case, nominal typing is safer; if you load a plugin that exports a type, you want to know exactly what that type is, not just any struct with the same fields. Semantic identity matters.\n\nWith structural typing, you could load a structurally compatible but semantically incorrect type without detecting it until runtime.\n\nThat said, I understand there are cases where structural typing would be useful; moving types between modules without breaking the ABI, for example. For those cases, an explicit annotation like #[abi_structural] could be the solution, similar to how #[repr(C)] already works today; nominal by default, opt-in for special behavior.\n\nRegarding the pkgid issue you mentioned, you’re right; crate names aren’t sufficient, and we’d need to include something equivalent to Cargo’s pkgid to resolve ambiguity.",
  "title": "Stable type identifiers: a missing piece for crABI and export"
}