update original

rustbook-en/src/ch04-02-references-and-borrowing.md

@@ -173,8 +173,8 @@ reading of the data.
 
 Note that a reference’s scope starts from where it is introduced and continues
 through the last time that reference is used. For instance, this code will
-compile because the last usage of the immutable references, the `println!`,
-occurs before the mutable reference is introduced:
+compile because the last usage of the immutable references is in the `println!`,
+before the mutable reference is introduced:
 
 ```rust,edition2021
 {{#rustdoc_include ../listings/ch04-understanding-ownership/no-listing-13-reference-scope-ends/src/main.rs:here}}

rustbook-en/src/ch04-03-slices.md

@@ -16,10 +16,12 @@ slices, to understand the problem that slices will solve:
 fn first_word(s: &String) -> ?
 ```
 
-The `first_word` function has a `&String` as a parameter. We don’t want
-ownership, so this is fine. But what should we return? We don’t really have a
-way to talk about _part_ of a string. However, we could return the index of the
-end of the word, indicated by a space. Let’s try that, as shown in Listing 4-7.
+The `first_word` function has a `&String` as a parameter. We don’t need
+ownership, so this is fine. (In idiomatic Rust, functions do not take ownership
+of their arguments unless they need to, and the reasons for that will become
+clear as we keep going!) But what should we return? We don’t really have a way
+to talk about part of a string. However, we could return the index of the end of
+the word, indicated by a space. Let’s try that, as shown in Listing 4-7.
 
 <Listing number="4-7" file-name="src/main.rs" caption="The `first_word` function that returns a byte index value into the `String` parameter">
 

rustbook-en/src/ch13-01-closures.md

@@ -330,12 +330,12 @@ called. If the `Option` is `None`, `f` will be called once. Because all
 closures implement `FnOnce`, `unwrap_or_else` accepts all three kinds of
 closures and is as flexible as it can be.
 
-> Note: Functions can implement all three of the `Fn` traits too. If what we
-> want to do doesn’t require capturing a value from the environment, we can use
-> the name of a function rather than a closure where we need something that
-> implements one of the `Fn` traits. For example, on an `Option<Vec<T>>` value,
-> we could call `unwrap_or_else(Vec::new)` to get a new, empty vector if the
-> value is `None`.
+> Note: If what we want to do doesn’t require capturing a value from the
+> environment, we can use the name of a function rather than a closure. For
+> example, we could call `unwrap_or_else(Vec::new)` on a `Option<Vec<T>>` value
+> to get a new, empty vector if the value is `None`. The compiler automatically
+> implements whichever of the `Fn` traits is applicable for a function
+> definition.
 
 Now let’s look at the standard library method `sort_by_key` defined on slices,
 to see how that differs from `unwrap_or_else` and why `sort_by_key` uses

rustbook-en/src/ch19-03-pattern-syntax.md

@@ -19,15 +19,15 @@ value.
 ### Matching Named Variables
 
 Named variables are irrefutable patterns that match any value, and we’ve used
-them many times in the book. However, there is a complication when you use
-named variables in `match` expressions. Because `match` starts a new scope,
-variables declared as part of a pattern inside the `match` expression will
-shadow those with the same name outside the `match` construct, as is the case
-with all variables. In Listing 19-11, we declare a variable named `x` with the
-value `Some(5)` and a variable `y` with the value `10`. We then create a
-`match` expression on the value `x`. Look at the patterns in the match arms and
-`println!` at the end, and try to figure out what the code will print before
-running this code or reading further.
+them many times in the book. However, there is a complication when you use named
+variables in `match`, `if let`, or `while let` expressions. Because each of
+these kinds of expression starts a new scope, variables declared as part of a
+pattern inside the expression will shadow those with the same name outside, as
+is the case with all variables. In Listing 19-11, we declare a variable named
+`x` with the value `Some(5)` and a variable `y` with the value `10`. We then
+create a `match` expression on the value `x`. Look at the patterns in the match
+arms and `println!` at the end, and try to figure out what the code will print
+before running this code or reading further.
 
 <Listing number="19-11" file-name="src/main.rs" caption="A `match` expression with an arm that introduces a new variable which shadows an existing variable `y`">
 
@@ -67,11 +67,10 @@ Guards”](#extra-conditionals-with-match-guards)<!-- ignore --> section.
 
 ### Multiple Patterns
 
-In `match` expressions, you can match multiple patterns using the `|` syntax,
-which is the pattern _or_ operator. For example, in the following code we match
-the value of `x` against the match arms, the first of which has an _or_ option,
-meaning if the value of `x` matches either of the values in that arm, that
-arm’s code will run:
+You can match multiple patterns using the `|` syntax, which is the pattern _or_
+operator. For example, in the following code we match the value of `x` against
+the match arms, the first of which has an _or_ option, meaning if the value of
+`x` matches either of the values in that arm, that arm’s code will run:
 
 ```rust
 {{#rustdoc_include ../listings/ch19-patterns-and-matching/no-listing-02-multiple-patterns/src/main.rs:here}}
@@ -452,7 +451,9 @@ compiler error because using `..` in two places like this is ambiguous.
 
 A _match guard_ is an additional `if` condition, specified after the pattern in
 a `match` arm, that must also match for that arm to be chosen. Match guards are
-useful for expressing more complex ideas than a pattern alone allows.
+useful for expressing more complex ideas than a pattern alone allows. They are
+only available in `match` expressions, not in `if let` or `while let`
+expressions.
 
 The condition can use variables created in the pattern. Listing 19-26 shows a
 `match` where the first arm has the pattern `Some(x)` and also has a match

rustbook-en/src/ch20-06-macros.md

@@ -118,8 +118,9 @@ for use in the replacement code. Within `$()` is `$x:expr`, which matches any
 Rust expression and gives the expression the name `$x`.
 
 The comma following `$()` indicates that a literal comma separator character
-could optionally appear after the code that matches the code in `$()`. The `*`
-specifies that the pattern matches zero or more of whatever precedes the `*`.
+must appear between each instance of the code that matches the code within
+`$()`. The `*` specifies that the pattern matches zero or more of whatever
+precedes the `*`.
 
 When we call this macro with `vec![1, 2, 3];`, the `$x` pattern matches three
 times with the three expressions `1`, `2`, and `3`.