The Hashtable Problem: A Litmus Test for External Impl Proposals

benschulz:

I'd love to be able to declare "I depend on the two unrelated crates miniserde and jiff" in my Cargo.toml . 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 , I ought to be able to define impls of miniserde::Serialize for jiff structs without risk of overlap due to changes upstream.

This works if only one crate can do this (the binary crate?)

But if two crates do this, then those impls can overlap.

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?). 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)

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.