{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreignddmst2mdczo7ol2pke23m6rpyhyppmoaq2nhdwh7gnf7xlgcga",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3miub77zzcd62"
  },
  "path": "/t/pre-pre-rfc-dynamic-library-proposal/24135#post_3",
  "publishedAt": "2026-04-05T19:23:57.000Z",
  "site": "https://internals.rust-lang.org",
  "textContent": "LouChiSoft:\n\n> No fixed ABI here, just the one that toolchain used at the time it was compiled.\n\nThis doesn't work very well the moment you have some kind of indirection. If your function accepts a `&Foo` then the ABI of the function cannot dictacte how to pass the `Foo` behind the reference. This in turns means that either the caller's `Foo` is the same as the dynamic library's or they are different `Foo`s.\n\nNow imagine if `Foo` is a stdlib type. The suddently you and the dynamic library are basically speaking two different dialects of Rust!\n\n* * *\n\nThis is also missing some safety measures at linking time. Are you just trusting that the library loaded at runtime will be ABI-compatible with the `.lib` provided? What about ABI-compatible changes though?\n\nNote that even if the Rust-level ABI is the same that doesn't mean a type cannot change (and in turn change its ABI) across different versions of a library!\n\n* * *\n\nFinally, I assume this doesn't aim to handle generics. This should be noted somewhere since generics always come up when talking about dynamic loading.",
  "title": "[Pre-Pre-RFC] Dynamic library proposal"
}