Skip to content

Commit e496215

Browse files
committed
Update orphan rule introduction
This updates the orphan rule introduction based on some conversations to try to emphasize a few points: - Say what it is before explaining why it exists. - Frame the rationale as saving space for crate authors.
1 parent 009ebdd commit e496215

File tree

1 file changed

+6
-8
lines changed

1 file changed

+6
-8
lines changed

src/items/implementations.md

+6-8
Original file line numberDiff line numberDiff line change
@@ -174,14 +174,12 @@ be instantiable with the same set of types for the input type parameters. -->
174174
r[items.impl.trait.orphan-rule]
175175
#### Orphan rules
176176

177-
r[items.impl.trait.orphan-rule.rationale]
178-
The orphan rule helps ensure that other people's code can't break your code, and vice versa.
179-
If an external crate implements an external trait for an external type, and your crate also
180-
implements the same trait for the same type, the compiler wouldn't know which implementation
181-
to use.\
182-
The orphan rule prevents this by requiring that either the trait or some type in the
183-
implementation is local to your crate, ensuring only one crate defines the implementation and
184-
thereby maintaining coherence.
177+
r[items.impl.trait.orphan-rule.intro]
178+
The *orphan rule* states that a trait implementation is only allowed if either the trait or at least one of the types in the implementation is defined in the current crate. It prevents conflicting trait implementations across different crates and is key to ensuring coherence.
179+
180+
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.
181+
182+
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.
185183

186184
r[items.impl.trait.orphan-rule.general]
187185
Given `impl<P1..=Pn> Trait<T1..=Tn> for T0`, an `impl` is valid only if at

0 commit comments

Comments
 (0)