Skip to content

Relax orphan rules for derived impls #1553

@golddranks

Description

@golddranks

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:

  1. 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.

  2. 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 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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    T-langRelevant to the language team, which will review and decide on the RFC.

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions