Ch. 18: use “dyn compatibility” instead of “object safety”

- Introduce the concept at the end of 18.2 when discussing the tradeoffs
  of dynamic dispatch, with a link to the reference. The link is not
  currently valid, because of the versioning timeline, but it will be
  when this stabilizes!
- In 18.3, simply replace “object safe” with “dyn compatible”. There is
  still probably not enough discussion of it, but with the introduction
  and link in 18.2, it is *probably* enough for now?

Author: chriskrycho

src/ch18-02-trait-objects.md

@@ -239,9 +239,12 @@ so it doesn’t know which method implemented on which type to call. Instead, at
 runtime, Rust uses the pointers inside the trait object to know which method to
 call. This lookup incurs a runtime cost that doesn’t occur with static
 dispatch. Dynamic dispatch also prevents the compiler from choosing to inline a
-method’s code, which in turn prevents some optimizations. However, we did get
-extra flexibility in the code that we wrote in Listing 18-5 and were able to
-support in Listing 18-9, so it’s a trade-off to consider.
+method’s code, which in turn prevents some optimizations, and Rust has some
+rules about where you can and cannot use dynamic dispatch, called [_dyn
+compatibility_][dyn-compat]. However, we did get extra flexibility in the code
+that we wrote in Listing 18-5 and were able to support in Listing 18-9, so it’s
+a trade-off to consider.
 
 [performance-of-code-using-generics]: ch10-01-syntax.html#performance-of-code-using-generics
 [dynamically-sized]: ch20-04-advanced-types.html#dynamically-sized-types-and-the-sized-trait
+[dyn-compat]: https://doc.rust-lang.org/reference/items/traits.html#dyn-compatibility

src/ch18-03-oo-design-patterns.md

@@ -349,9 +349,9 @@ another design pattern.
 Another downside is that we’ve duplicated some logic. To eliminate some of the
 duplication, we might try to make default implementations for the
 `request_review` and `approve` methods on the `State` trait that return `self`;
-however, this would violate object safety, because the trait doesn’t know what
+however, this would not be dyn compatible, because the trait doesn’t know what
 the concrete `self` will be exactly. We want to be able to use `State` as a
-trait object, so we need its methods to be object safe.
+trait object, so we need its methods to be dyn compatible.
 
 Other duplication includes the similar implementations of the `request_review`
 and `approve` methods on `Post`. Both methods delegate to the implementation of