The Hashtable Problem: A Litmus Test for External Impl Proposals

viruscamp:

Any proposal aiming to relax the orphan rule or enable external trait implementations must address the hashtable problem.

This is only true for proposals that intend to allow overlapping implementations.

I'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.

I don't remember instances of running into the orphan rule that wouldn't be solved by such a construct.

1. This would need to be enforced by cargo. ↩︎

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. ↩︎