Various fixes to improve clarity for explanations of structs & tuples, named-field/tuple-like structs, and a lifetime diagram. #4308
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fix 1:
Ch 5 -> 5.1. Defining and Instantiating Structs
The current version of this chapter reads that structs and tuples "both hold multiple related values." This language excludes those structs and tuples which happen to hold between
0
-1
values. By inserting the word "can" into this, we can keep the emphasis on structs' and tuples' capacity for holding multiple sub-items, while still leaving room for the other cases to exist too.Fix 2:
Ch 5 -> 5.1. Defining and Instantiating Structs
Similarly, a later sentence in the same chapter currently reads "in a struct you’ll name each piece of data so it’s clear what the values mean." This language implies an obligation to name struct fields, excluding tuple structs. By replacing "you’ll" with "you can", we can be inclusive of tuple structs, while still emphasizing the power that comes with named fields.
Fix 3:
Ch 10 -> 10.3. Validating References with Lifetimes: -> The Borrow Checker
Listing 10-18 currently has a misleading diagram, as the end of the
'a
lifetime is represented as ending before the ending of the'b
lifetime, when they actually both experience end-of-scope at the same point: the closing curly bracket. I've added a change to have this updated as well.Before:
After: