You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: src/doc/book/src/traits.md
+12-6Lines changed: 12 additions & 6 deletions
Original file line number
Diff line number
Diff line change
@@ -23,7 +23,8 @@ impl Circle {
23
23
[methodsyntax]: method-syntax.html
24
24
25
25
Traits are similar, except that we first define a trait with a method
26
-
signature, then implement the trait for a type. In this example, we implement the trait `HasArea` for `Circle`:
26
+
signature, then implement the trait for a type. In this example, we implement
27
+
the trait `HasArea` for `Circle`:
27
28
28
29
```rust
29
30
structCircle {
@@ -78,8 +79,8 @@ impl HasArea for Circle {
78
79
## Trait bounds on generic functions
79
80
80
81
Traits are useful because they allow a type to make certain promises about its
81
-
behavior. Generic functions can exploit this to constrain, or [bound][bounds], the types they
82
-
accept. Consider this function, which does not compile:
82
+
behavior. Generic functions can exploit this to constrain, or [bound][bounds],
83
+
the types they accept. Consider this function, which does not compile:
83
84
84
85
[bounds]: glossary.html#bounds
85
86
@@ -427,13 +428,16 @@ fn inverse<T>(x: i32) -> T
427
428
```
428
429
429
430
This shows off the additional feature of `where` clauses: they allow bounds
430
-
on the left-hand side not only of type parameters `T`, but also of types (`i32` in this case). In this example, `i32` must implement
431
+
on the left-hand side not only of type parameters `T`, but also of types
432
+
(`i32` in this case). In this example, `i32` must implement
431
433
`ConvertTo<T>`. Rather than defining what `i32` is (since that's obvious), the
432
434
`where` clause here constrains `T`.
433
435
434
436
# Default methods
435
437
436
-
A default method can be added to a trait definition if it is already known how a typical implementor will define a method. For example, `is_invalid()` is defined as the opposite of `is_valid()`:
438
+
A default method can be added to a trait definition if it is already known how
439
+
a typical implementor will define a method. For example, `is_invalid()` is
440
+
defined as the opposite of `is_valid()`:
437
441
438
442
```rust
439
443
traitFoo {
@@ -443,7 +447,9 @@ trait Foo {
443
447
}
444
448
```
445
449
446
-
Implementors of the `Foo` trait need to implement `is_valid()` but not `is_invalid()` due to the added default behavior. This default behavior can still be overridden as in:
450
+
Implementors of the `Foo` trait need to implement `is_valid()` but not
451
+
`is_invalid()` due to the added default behavior. This default behavior can
0 commit comments