Ch17-03 Mentions Object Safety with Little Explanation

[LukeFranceschini]

trafficstars

• I have searched open and closed issues and pull requests for duplicates, using these search terms:
  • object safety
• I have checked the latest main branch to see if this has already been fixed, in this file:
  • https://github.com/rust-lang/book/blob/main/src/ch17-03-oo-design-patterns.md

URL to the section(s) of the book with this problem: https://doc.rust-lang.org/book/ch17-03-oo-design-patterns.html

Description of the problem: The book references object safety in chapter 17.3 without mentioning it anywhere else in the entire book. The duplicate logic section explains that the duplication is necessary to maintain object safety as if the user should be aware of the meaning of object safety. However, the object safety section was removed in 727ef100 after discussion in #2787 and #2790. This removed section would have given some background context for the duplicate logic paragraph in chapter 17.3. Without that section, this paragraph about duplicate implementation is quite confusing, requiring the reader (or at least me) to Google what object safety means to understand the issue.

Suggested fix: I'm not sure what would make the most sense here:

• giving a slightly longer paragraph explaining why the compiler needs to know the size of the object at compile time
• saying the duplicate logic is required for a handwaved reason about the way traits are implemented that you can read about in the reference (with a link to the relevant section of the reference)
• removing this paragraph like the rest of the section about object safety

The next paragraph talks about duplicate implementation anyway, so there would still be discussion about that issue if the object safety paragraph was removed. I know there were several other pull requests and issues discussing the object safety section, and it was slowly reduced in size until it was removed entirely. Maybe this would just be the final nail in the object safety coffin.

In any case, I thought I'd bring it up after the confusion it caused me when reading this section. I'd be happy to help with any changes that need to be made, but I figured I'd check to see what we think the best course of action is first. Thanks!

[chriskrycho]

Ah, interesting bit of evolution of the text there—thanks for opening this! We will think on the best way to proceed.

[chriskrycho]

We should also update it to use the language of “dyn compatibility”, since the language has intentionally switched to that—and wow is it ever a less confusing term!

[chriskrycho]

I opened #4129 to address this. It very briefly—just a single sentence—introduces the concept and links to the reference for it at the end of 18.2, so that the reference in 18.3 is not free-standing. In both cases, I used “dyn compatibility” rather than “object safety”. I think short of radically rewriting that whole section, that is probably the best we can do at this point.