Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix a couple inverted uses of “shadowed” #4121

Merged
merged 1 commit into from
Dec 2, 2024
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
16 changes: 8 additions & 8 deletions src/ch12-05-working-with-environment-variables.md
Original file line number Diff line number Diff line change
Expand Up @@ -55,14 +55,14 @@ they’ll be the same case when we check whether the line contains the query.

</Listing>

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
Expand Down
14 changes: 7 additions & 7 deletions src/ch19-01-all-the-places-for-patterns.md
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down
14 changes: 7 additions & 7 deletions src/ch19-03-pattern-syntax.md
Original file line number Diff line number Diff line change
Expand Up @@ -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.

<Listing number="19-11" file-name="src/main.rs" caption="A `match` expression with an arm that introduces a shadowed variable `y`">
<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`">

```rust
{{#rustdoc_include ../listings/ch19-patterns-and-matching/listing-19-11/src/main.rs:here}}
Expand Down Expand Up @@ -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)<!--
ignore --> 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)<!-- ignore --> section.

### Multiple Patterns

Expand Down Expand Up @@ -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`.

Expand Down