1
1
# Coercions
2
2
3
- Types can implicitly be coerced to change in certain contexts. These changes are
4
- generally just * weakening* of types, largely focused around pointers and
5
- lifetimes. They mostly exist to make Rust "just work" in more cases, and are
6
- largely harmless.
3
+ Types can implicitly be coerced to change in certain contexts.
4
+ These changes are generally just * weakening* of types, largely focused around pointers and lifetimes.
5
+ They mostly exist to make Rust "just work" in more cases, and are largely harmless.
7
6
8
7
For an exhaustive list of all the types of coercions, see the [ Coercion types] section on the reference.
9
8
10
9
## Cases where coercions do not perform
11
10
12
- Note that we do not perform coercions when matching traits (except for
13
- receivers, see below). If there is an impl for some type ` U ` and ` T ` coerces to
14
- ` U ` , that does not constitute an implementation for ` T ` . For example, the
15
- following will not type check, even though it is OK to coerce ` t ` to ` &T ` and
16
- there is an impl for ` &T ` :
11
+ Note that we do not perform coercions when matching traits (except for receivers, see below).
12
+ If there is an ` impl ` for some type ` U ` and ` T ` coerces to ` U ` , that does not constitute an implementation for ` T ` .
13
+ For example, the following will not type check, even though it is OK to coerce ` t ` to ` &T ` and there is an ` impl ` for ` &T ` :
17
14
18
15
``` rust,compile_fail
19
16
trait Trait {}
@@ -28,6 +25,8 @@ fn main() {
28
25
}
29
26
```
30
27
28
+ which fails like the following:
29
+
31
30
``` text
32
31
error[E0277]: the trait bound `&mut i32: Trait` is not satisfied
33
32
--> src/main.rs:9:9
0 commit comments