Comment by 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.
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.
You are being modest in explanation.
That's not a downside, that's dependency hell with Trait coherency landmines.