{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreihqruxtwoas2xqjdpra42jaoingbhp2nff6byussauwi74k4nt5bm",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mo622qjx53n2"
  },
  "path": "/t/the-hashtable-problem-a-litmus-test-for-external-impl-proposals/24396#post_5",
  "publishedAt": "2026-06-13T09:24:04.000Z",
  "site": "https://internals.rust-lang.org",
  "tags": [
    "[1]",
    "[2]",
    "↩︎",
    "SemVer Compatibility chapter"
  ],
  "textContent": "viruscamp:\n\n> Any proposal aiming to relax the orphan rule or enable external trait implementations must address the hashtable problem.\n\nThis is only true for proposals that intend to allow overlapping implementations.\n\nI'd love to be able to declare \"I depend on the two _unrelated_ crates `miniserde` and `jiff`\" in my `Cargo.toml`[1]. By unrelated I mean that `miniserde` does not depend on `jiff` nor does `jiff` depend on `miniserde`. Having ruled that out, and assuming that neither adds any blanket impls or a dependency on the other[2], I ought to be able to define impls of `miniserde::Serialize` for `jiff` structs without risk of overlap due to changes upstream.\n\nI don't remember instances of running into the orphan rule that wouldn't be solved by such a construct.\n\n* * *\n\n  1. This would need to be enforced by cargo. ↩︎\n\n  2. This would be a new \"possibly-breaking change\" to be listed in the SemVer Compatibility chapter. This rule may seem dubious, but in practice it seems defensible. Assuming a new crate such as `jiff-miniserde` or `miniserde-jiff`, I think such breakage would be highly unlikely in practice. ↩︎\n\n\n",
  "title": "The Hashtable Problem: A Litmus Test for External Impl Proposals"
}