@@ -33,10 +33,10 @@ SomeTrait for SomeTrait { ... }`, but that seems weird and confusing and rather
33
33
like boilerplate. Note that the precise mechanism here is out of scope for this
34
34
RFC).
35
35
36
- This is only sound if the trait is / object-safe/ . We say a method ` m ` on trait
36
+ This is only sound if the trait is object-safe. We say a method ` m ` on trait
37
37
` T ` is object-safe if it is legal (in current Rust) to call ` x.m(...) ` where ` x `
38
- has type ` &T ` , i.e., ` x ` is a trait object. If all methods in ` T ` are object-
39
- safe, then we say ` T ` is object-safe.
38
+ has type ` &T ` , i.e., ` x ` is a trait object. If all methods in ` T ` are object-safe,
39
+ then we say ` T ` is object-safe.
40
40
41
41
If we ignore this restriction we could allow code such as the following:
42
42
@@ -61,8 +61,8 @@ traits. This makes both method call and using trait objects with generic code
61
61
simpler. The downside is that it makes Rust less flexible, since not all traits
62
62
can be used to create trait objects.
63
63
64
- Software evolution is improved with this proposal: imagine adding a non-object-
65
- safe method to a previously object-safe trait. With this proposal, you would
64
+ Software evolution is improved with this proposal: imagine adding a non-object-safe
65
+ method to a previously object-safe trait. With this proposal, you would
66
66
then get errors wherever a trait-object is created. The error would explain why
67
67
the trait object could not be created and point out exactly which method was to
68
68
blame and why. Without this proposal, the only errors you would get would be
0 commit comments