{"action":"opened","issue":{"url":"https://api.github.com/repos/rust-lang/rfcs/issues/1553","repository_url":"https://api.github.com/repos/rust-lang/rfcs","labels_url":"https://api.github.com/repos/rust-lang/rfcs/issues/1553/labels{/name}","comments_url":"https://api.github.com/repos/rust-lang/rfcs/issues/1553/comments","events_url":"https://api.github.com/repos/rust-lang/rfcs/issues/1553/events","html_url":"https://github.com/rust-lang/rfcs/issues/1553","id":142845496,"number":1553,"title":"Relax orphan rules for derived impls","user":{"login":"golddranks","id":2675542,"avatar_url":"https://avatars.githubusercontent.com/u/2675542?v=3","gravatar_id":"","url":"https://api.github.com/users/golddranks","html_url":"https://github.com/golddranks","followers_url":"https://api.github.com/users/golddranks/followers","following_url":"https://api.github.com/users/golddranks/following{/other_user}","gists_url":"https://api.github.com/users/golddranks/gists{/gist_id}","starred_url":"https://api.github.com/users/golddranks/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/golddranks/subscriptions","organizations_url":"https://api.github.com/users/golddranks/orgs","repos_url":"https://api.github.com/users/golddranks/repos","events_url":"https://api.github.com/users/golddranks/events{/privacy}","received_events_url":"https://api.github.com/users/golddranks/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":0,"created_at":"2016-03-23T03:06:10Z","updated_at":"2016-03-23T03:06:10Z","closed_at":null,"body":"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 it at the same time it prevents implementing some common traits for types whose authors didn't have the foresight to implement the traits for.\r\n\r\nIt 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.\r\n\r\nOf 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.\r\n\r\nI didn't write this a full-blown RFC yet, because there's some blockers:\r\n\r\n1) 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](https://gist.github.com/nikomatsakis/d5fe4a4b5b075b3d0ec9) should help, as they allow to explicitly represent this intention.\r\n\r\n2) I'm not sure what's the story about deriving impls for other than `std` traits. If there's eventually going to be a stable way to define compiler plugins for deriving implementations, there should be limitation that only the trait author has the ability to define a 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 plugins by the trait author are allowed to be used by downstream crates to derive impls for upstream types."}}