Skip to content

Commit 9624b68

Browse files
committed
book: Clarify that trait or type must be in same crate as impl
1 parent 8f36038 commit 9624b68

File tree

1 file changed

+9
-5
lines changed

1 file changed

+9
-5
lines changed

src/doc/book/traits.md

Lines changed: 9 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -277,11 +277,15 @@ This will compile without error.
277277
This means that even if someone does something bad like add methods to `i32`,
278278
it won’t affect you, unless you `use` that trait.
279279

280-
There’s one more restriction on implementing traits: either the trait, or the
281-
type you’re writing the `impl` for, must be defined by you. So, we could
282-
implement the `HasArea` type for `i32`, because `HasArea` is in our code. But
283-
if we tried to implement `ToString`, a trait provided by Rust, for `i32`, we could
284-
not, because neither the trait nor the type are in our code.
280+
There’s one more restriction on implementing traits: either the trait
281+
or the type you’re implementing it for must be defined by you. Or more
282+
precisely, one of them must be defined in the same crate as the `impl`
283+
you're writing.
284+
285+
So, we could implement the `HasArea` type for `i32`, because we defined
286+
`HasArea` in our code. But if we tried to implement `ToString`, a trait
287+
provided by Rust, for `i32`, we could not, because neither the trait nor
288+
the type are defined in our crate.
285289

286290
One last thing about traits: generic functions with a trait bound use
287291
‘monomorphization’ (mono: one, morph: form), so they are statically dispatched.

0 commit comments

Comments
 (0)