diff --git a/rustbook-en/src/ch04-02-references-and-borrowing.md b/rustbook-en/src/ch04-02-references-and-borrowing.md index 22ceb2bd..4cc98fb1 100644 --- a/rustbook-en/src/ch04-02-references-and-borrowing.md +++ b/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}} diff --git a/rustbook-en/src/ch04-03-slices.md b/rustbook-en/src/ch04-03-slices.md index 6a0bb081..440653e4 100644 --- a/rustbook-en/src/ch04-03-slices.md +++ b/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. diff --git a/rustbook-en/src/ch13-01-closures.md b/rustbook-en/src/ch13-01-closures.md index 3f4e50cf..4aa336e1 100644 --- a/rustbook-en/src/ch13-01-closures.md +++ b/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>` 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>` 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 diff --git a/rustbook-en/src/ch19-03-pattern-syntax.md b/rustbook-en/src/ch19-03-pattern-syntax.md index 21c1137d..d685f87b 100644 --- a/rustbook-en/src/ch19-03-pattern-syntax.md +++ b/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. @@ -67,11 +67,10 @@ Guards”](#extra-conditionals-with-match-guards) 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 diff --git a/rustbook-en/src/ch20-06-macros.md b/rustbook-en/src/ch20-06-macros.md index c687c8b6..edc5fc4c 100644 --- a/rustbook-en/src/ch20-06-macros.md +++ b/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`.