3 ms·
Assuming you have no control over trait implementation, how would that work? To reuse the canonic example: // crate "types" pub struct Thing; //
by 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 agoYes, 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 agoYou are being modest in explanation. That's not a downside, that's dependency hell with Trait coherency landmines.