4 ms·

> But you still need a resolution mechanism to fix the error At least initially, the resolution mechanism could be "don't include more than one implementation"

• Ygg2 3y ago
  Assuming you have no control over trait implementation, how would that work? To reuse the canonic example: // crate "types" pub struct Thing; // crate "traits" pub trait Action {} // crate "alpha_v0" impl traits::Action for types::Thing {} // crate "beta_v1" impl traits::Action for types::Thing {} // Doesn't exist for beta_v0 Say by transitive dependencies, alpha_v0 and beta_v0 are imported, and due to vulnerability, you upgrade beta_v0 -> beta_v1 (let's assume that trait is essential for the vulnerability resolution). Now what? You either have to skip future updates, or keep the vulnerable beta_v0 crate.
  • JoshTriplett 3y ago
    Yes, that's the downside of relaxing the orphan rule. That doesn't mean there has to be a way for the top-level crate to work around that, other than avoiding having both of those in its dependency tree. Ideally, people would tend to put trait implementations for a given pair of crates in a unique library crate, implement them in the obvious way, and provide that as a library for people to use.
    • Ygg2 3y ago
      You are being modest in explanation. That's not a downside, that's dependency hell with Trait coherency landmines.