Revisit Orphan Rules

[Ixrec]

I think this has been rejected in the past because having no conflict resolution strategy at all means eventually someone's going to pull in two crates that impl T for S, and then there's simply nothing they can do to make that code compile. Then, at best, we're back to crates doing "defensive newtyping" to avoid this problem.

Also, we should probably stop using Serialize as the example, since as stated above we'd never want serde to use such an opt-out even if it was added to the language for good reason. Unless serde added a separate NonPersistSerialize trait or something.

---

Edit:

@mboratko

it also appears to say that any non-generic function lacking the same exact set of impl annotations would simply not compile if it called or was called by bar

Yes, that’s not what I was suggesting, but I don’t see where the gist suggests this is the case.

That was my interpretation of:

As a result, the compiler will specify a type error at the call Module2::bar(h) in Module1::foo(), because the type of the parameter h in bar() does not match the type of the value being provided (the implementation modules do not match).

afaict, that's the only sentence in the gist about the semantics of a non-generic function with impl annotations in the signature, so maybe there are other ways to interpret this.