Fixing small mistakes found in page review

second-edition/src/ch13-00-functional-features.md

@@ -4,10 +4,11 @@ Rust’s design has taken inspiration from many existing languages and
 techniques, and one significant influence is *functional programming*.
 Programming in a functional style often includes using functions as values by
 passing them in arguments, returning them from other functions, assigning them
-to variables for later execution, and so forth. In this chapter, we won’t
-debate the issue of what functional programming is or isn’t but will instead
-discuss some features of Rust that are similar to features in many languages
-often referred to as functional.
+to variables for later execution, and so forth.
+
+In this chapter, we won’t debate the issue of what functional programming is or
+isn’t but will instead discuss some features of Rust that are similar to
+features in many languages often referred to as functional.
 
 More specifically, we’ll cover:
 

second-edition/src/ch13-01-closures.md

@@ -334,7 +334,7 @@ available.
 
 Like variables, we can add type annotations if we want to increase explicitness
 and clarity at the cost of being more verbose than is strictly necessary;
-annotating the types for the closure we defined in Listing 13-4 would look like
+annotating the types for the closure we defined in Listing 13-5 would look like
 the definition shown in Listing 13-7:
 
 <span class="filename">Filename: src/main.rs</span>
@@ -437,8 +437,8 @@ we use generics and trait bounds, as we discussed in Chapter 10.
 
 The `Fn` traits are provided by the standard library. All closures implement at
 least one of the traits: `Fn`, `FnMut`, or `FnOnce`. We’ll discuss the
-difference between these traits in the next section on capturing the
-environment; in this example, we can use the `Fn` trait.
+difference between these traits in the "Capturing the Environment with
+Closures" section; in this example, we can use the `Fn` trait.
 
 We add types to the `Fn` trait bound to represent the types of the parameters
 and return values the closures must have to match this trait bound. In this
@@ -745,7 +745,7 @@ their environment, defining and using functions will never incur this overhead.
 
 Closures can capture values from their environment in three ways, which
 directly map to the three ways a function can take a parameter: taking
-ownership, borrowing immutably, and borrowing mutably. These are encoded in the
+ownership, borrowing mutably, and borrowing immutably. These are encoded in the
 three `Fn` traits as follows:
 
 * `FnOnce` consumes the variables it captures from its enclosing scope, known

second-edition/src/ch13-02-iterators.md

@@ -39,8 +39,7 @@ for val in v1_iter {
 }
 ```
 
-<span class="caption">Listing 13-14: Making use of an iterator in a `for`
-loop</span>
+<span class="caption">Listing 13-14: Using an iterator in a `for` loop</span>
 
 In languages that don’t have iterators provided by their standard libraries, we
 would likely write this same functionality by starting a variable at index 0,
@@ -195,9 +194,9 @@ The code in Listing 13-17 doesn’t do anything; the closure we’ve specified
 never gets called. The warning reminds us why: iterator adaptors are lazy, and
 we need to consume the iterator here.
 
-To fix this and consume the iterator, we’ll use the `collect` method, which you
-saw briefly in Chapter 12. This method consumes the iterator and collects the
-resulting values into a collection data type.
+To fix this and consume the iterator, we’ll use the `collect` method, which we
+used in Chapter 12 with `env::args` in Listing 12-1. This method consumes the
+iterator and collects the resulting values into a collection data type.
 
 In Listing 13-18, we collect the results of iterating over the iterator that’s
 returned from the call to `map` into a vector. This vector will end up