Comment by JoshTriplett
9 months ago
I would love to make it possible to bypass the orphan rule in general, including for crates published on crates.io. This is an important issue for ecosystem scaling, in many different ways.
It means that if you have a library A providing a trait and a library B providing a type, either A has to add optional support for B or B has to add optional support for A, or someone has to hack around that with a newtype wrapper. Usually, whichever library is less popular ends up adding optional support for the more popular library. This is, for instance, one reason why it's really really hard to write a replacement for serde: you'd have to get every crate currently providing optional serde support to provide optional support for your library as well.
In other ecosystems, you'd either add quick-and-dirty support in your application, or you'd write (and perhaps publish) an A-B crate that implements support for using A and B together. This should be possible in Rust.
Oh, 100%, I'd be happy with that too.
Is the orphan rule a result of some technical limitation? Or just the idea that it's "unclean" to implement someone elses traits for someone elses types?
Hi from Haskell land!
Haskell went through this as well. Orphans used to be allowed and I certainly saw their appeal.
The problem is that the compiler might see two different implementations of ToString for MyType in different source files. The compiler could probably make a check for that if it were compiling both files at once, but if you want to be able to compile source files separately and only recompile files which have changed, etc., I think it gets harder to spot.
> someone has to hack around that with a newtype wrapper
Don't think of it as hacking around it. It's the blessed approach. Newtype wrapping is giving a proper names to the behaviours, so that they don't get mixed up.