-
Notifications
You must be signed in to change notification settings - Fork 1.7k
Relax orphan rules for derived impls #1553
Description
The current orphan rules prevent implementing an external trait for an external type, preventing multiple different implementations for any pair of (trait, type). This restriction on downstream crates is to preserve coherence, but at the same time it prevents implementing some common traits for types whose authors didn't have the foresight to implement the traits for.
It just occurred to me, that while orphan impls are troublesome when they are hand-crafted, derived impls shouldn't have any problem with coherence. Why? Because if the impl is algorithmically derived by the compiler, it's going to be the same no matter where it is derived.
Of course, this assumes that only the trait author (or the compiler itself) has the control to define the derivation algorithm, i.e. the compiler plugin that does the derivation. That's actually just another way to say that there is no coherence issues because the implementation is originally by the trait author, whether or not he/she triggered the derivation for a specific type.
I didn't write this into a full-blown RFC yet, because there's some blockers:
-
If the orphan rules are relaxed, the downstream crates become able to derive traits for upstream types. But the type authors may have meant their types NOT to implement a trait. Currently it's possible to do this by just not implementing the trait, because the orphan rules prevent others from doing so. But this is essentially negative reasoning, which is frowned upon. Negative impls should help, as they allow to explicitly represent this intention.
-
I'm not sure what's the story about deriving impls for other than
stdtraits. If there's eventually going to be a stable way to define compiler plugins for deriving implementations, there should be a limitation that only the trait author has the ability to define the deriving plugin for his/her trait, otherwise the orphan rules can't be relaxed. Of course, this rule, in turn, could be relaxed so that anyone is able to define deriving plugins for any traits, but only the plugin by the trait author is allowed to be used by downstream crates to derive impls for upstream types.