Fix example in orphan rule rationale #1960
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
rustbot
added
the
S-waiting-on-review
Imberflur
commented
Aug 14, 2025
| @@ -178,7 +178,7 @@ The *orphan rule* states that a trait implementation is only allowed if either t | |||
|
|
|||
| An orphan implementation is one that implements a foreign trait for a foreign type. If these were freely allowed, two crates could implement the same trait for the same type in incompatible ways, creating a situation where adding or updating a dependency could break compilation due to conflicting implementations. | |||
|
|
|||
| The orphan rule enables library authors to add new implementations to their traits without fear that they'll break downstream code. Without these restrictions, a library couldn't add an implementation like `impl<T: Display> MyTrait for T` without potentially conflicting with downstream implementations. | |||
| The orphan rule enables library authors to add new implementations to their traits without fear that they'll break downstream code. Without these restrictions, a library couldn't add an implementation like `impl<T: Display> Trait for LocalGenericType<T>` without potentially conflicting with downstream implementations. | |||
There was a problem hiding this comment.
Suggested change
| The orphan rule enables library authors to add new implementations to their traits without fear that they'll break downstream code. Without these restrictions, a library couldn't add an implementation like `impl<T: Display> Trait for LocalGenericType<T>` without potentially conflicting with downstream implementations. | |
| The orphan rule enables library authors to add new implementations to their traits without fear that they'll break downstream code. With these restrictions, a library can add an implementation like `impl<T: Display> Trait for LocalGenericType<T>` without potentially conflicting with downstream implementations. |
Thinking about removing the double negative here
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The orphan rule doesn't prevent the case of
impl<T: Display> MyTrait for Tfrom breaking downstream. That would involve preventing downstream impls even on local downstream types. What it does prevent is downstream impls on generic types from a library.