Comment by JoshTriplett

9 months ago

> 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".

3 comments

JoshTriplett

Reply
Ygg2  9 months 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  9 months 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  9 months ago

      You are being modest in explanation.

      That's not a downside, that's dependency hell with Trait coherency landmines.