diff --git a/src/ch12-05-working-with-environment-variables.md b/src/ch12-05-working-with-environment-variables.md index c56a285caa..630f98cb2f 100644 --- a/src/ch12-05-working-with-environment-variables.md +++ b/src/ch12-05-working-with-environment-variables.md @@ -55,14 +55,14 @@ they’ll be the same case when we check whether the line contains the query. -First we lowercase the `query` string and store it in a shadowed variable with -the same name. Calling `to_lowercase` on the query is necessary so that no -matter whether the user’s query is `"rust"`, `"RUST"`, `"Rust"`, or `"rUsT"`, -we’ll treat the query as if it were `"rust"` and be insensitive to the case. -While `to_lowercase` will handle basic Unicode, it won’t be 100% accurate. If -we were writing a real application, we’d want to do a bit more work here, but -this section is about environment variables, not Unicode, so we’ll leave it at -that here. +First we lowercase the `query` string and store it in a new variable with the +same name, shadowing the original. Calling `to_lowercase` on the query is +necessary so that no matter whether the user’s query is `"rust"`, `"RUST"`, +`"Rust"`, or `"rUsT"`, we’ll treat the query as if it were `"rust"` and be +insensitive to the case. While `to_lowercase` will handle basic Unicode, it +won’t be 100% accurate. If we were writing a real application, we’d want to do a +bit more work here, but this section is about environment variables, not +Unicode, so we’ll leave it at that here. Note that `query` is now a `String` rather than a string slice because calling `to_lowercase` creates new data rather than referencing existing data. Say the diff --git a/src/ch19-01-all-the-places-for-patterns.md b/src/ch19-01-all-the-places-for-patterns.md index 03d132954d..5200a01b52 100644 --- a/src/ch19-01-all-the-places-for-patterns.md +++ b/src/ch19-01-all-the-places-for-patterns.md @@ -82,13 +82,13 @@ This conditional structure lets us support complex requirements. With the hardcoded values we have here, this example will print `Using purple as the background color`. -You can see that `if let` can also introduce shadowed variables in the same way -that `match` arms can: the line `if let Ok(age) = age` introduces a new -shadowed `age` variable that contains the value inside the `Ok` variant. This -means we need to place the `if age > 30` condition within that block: we can’t -combine these two conditions into `if let Ok(age) = age && age > 30`. The -shadowed `age` we want to compare to 30 isn’t valid until the new scope starts -with the curly bracket. +You can see that `if let` can also introduce new variables which shadow existing +variables in the same way that `match` arms can: the line `if let Ok(age) = age` +introduces a new shadowed `age` variable that contains the value inside the `Ok` +variant. This means we need to place the `if age > 30` condition within that +block: we can’t combine these two conditions into `if let Ok(age) = age && age > +30`. The shadowed `age` we want to compare to 30 isn’t valid until the new scope +starts with the curly bracket. The downside of using `if let` expressions is that the compiler doesn’t check for exhaustiveness, whereas with `match` expressions it does. If we omitted the diff --git a/src/ch19-03-pattern-syntax.md b/src/ch19-03-pattern-syntax.md index 4a471bd670..4503cf77eb 100644 --- a/src/ch19-03-pattern-syntax.md +++ b/src/ch19-03-pattern-syntax.md @@ -29,7 +29,7 @@ value `Some(5)` and a variable `y` with the value `10`. We then create a `println!` at the end, and try to figure out what the code will print before running this code or reading further. -+ ```rust {{#rustdoc_include ../listings/ch19-patterns-and-matching/listing-19-11/src/main.rs:here}} @@ -60,10 +60,10 @@ When the `match` expression is done, its scope ends, and so does the scope of the inner `y`. The last `println!` produces `at the end: x = Some(5), y = 10`. To create a `match` expression that compares the values of the outer `x` and -`y`, rather than introducing a shadowed variable, we would need to use a match -guard conditional instead. We’ll talk about match guards later in the [“Extra -Conditionals with Match Guards”](#extra-conditionals-with-match-guards) section. +`y`, rather than introducing a new variable which shadows the existing `y` +variable, we would need to use a match guard conditional instead. We’ll talk +about match guards later in the [“Extra Conditionals with Match +Guards”](#extra-conditionals-with-match-guards) section. ### Multiple Patterns @@ -503,8 +503,8 @@ pattern as `Some(y)`, which would have shadowed the outer `y`, we specify `Some(n)`. This creates a new variable `n` that doesn’t shadow anything because there is no `n` variable outside the `match`. -The match guard `if n == y` is not a pattern and therefore doesn’t introduce -new variables. This `y` *is* the outer `y` rather than a new shadowed `y`, and +The match guard `if n == y` is not a pattern and therefore doesn’t introduce new +variables. This `y` *is* the outer `y` rather than a new `y` shadowing it, and we can look for a value that has the same value as the outer `y` by comparing `n` to `y`.