{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreifxzv6lswi642ikukyet4azejcfjtlwg4dq4lk36c7ltoo4btr54e",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mo6aqivgdq72"
  },
  "path": "/t/the-hashtable-problem-a-litmus-test-for-external-impl-proposals/24396#post_10",
  "publishedAt": "2026-06-13T12:15:04.000Z",
  "site": "https://internals.rust-lang.org",
  "tags": [
    "crates.io"
  ],
  "textContent": "My core point was supposed to be that, in my experience, overlapping impls aren't necessary and that the hashtable problem may be a bad and/or overly strict test.\n\n(The rest of this post is going somewhat off-topic.)\n\ndlight:\n\n> This works if only one crate can do this (the binary crate?)\n>\n> But if two crates do this, then those impls can overlap.\n\nAbsolutely. Only one crate in the crate graph can be allowed to exploit the independence between `miniserde` and `jiff`.\n\ndlight:\n\n> My preferred solution for those kinds of global constraints is to just fail compilation in that case (the problem is, fail where? in the linker?).\n\nYes, compilation should fail. In Ben's world of fantasy and wonder, modules and crates could be generic. Importantly, that would allow adding (trivial) bounds. Any crate could then declare that `jiff::Timestamp: miniserde::Serialize` must hold. These constraints would \"bubble up\" to the binary crate which would have to ensure they hold.\n\ndlight:\n\n> And more importantly, disallow uploading such crates with non-local impls to crates.io (make it require a field in `Cargo.toml` that says the crate is not for consumption of the wide ecosystem)\n>\n> So you can have some odd, non-composable crate in your own project, and it will be perpetually fragile (what if a new version of `jiff` depends on `miniserde`), and that's okay because it's contained. But you absolutely shouldn't be able to publish this duct-taped crate to the wider ecosystem and allow other crates depend on it.\n\nI think this is letting the perfect be the enemy of the good. It's unlikely that `jiff` will start to depend on `miniserde`. So the expected cost is low and the expected utility is huge: Fewer implementations means less effort spent, fewer sources of bugs, and increased compatibility.\n\nTamschi:\n\n> This would not be (much of) an issue for executable-only crates, which would already cover a lot of ground in practice. There may be some ecosystem tradeoffs in terms of fewer stand-alone binaries being made also usable as libraries.\n\nThat is true. For maximum flexibility, there would have to be separate packages for the library and the binary.",
  "title": "The Hashtable Problem: A Litmus Test for External Impl Proposals"
}