From 9fc8bc7071f7c8aba842841facf24157f16103cb Mon Sep 17 00:00:00 2001 From: "Carol (Nichols || Goulding)" Date: Fri, 23 Feb 2018 10:46:08 -0500 Subject: [PATCH] Fixing small mistakes found in page review --- second-edition/src/ch13-00-functional-features.md | 9 +++++---- second-edition/src/ch13-01-closures.md | 8 ++++---- second-edition/src/ch13-02-iterators.md | 9 ++++----- 3 files changed, 13 insertions(+), 13 deletions(-) diff --git a/second-edition/src/ch13-00-functional-features.md b/second-edition/src/ch13-00-functional-features.md index 50eab0940..eadf5cc35 100644 --- a/second-edition/src/ch13-00-functional-features.md +++ b/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: diff --git a/second-edition/src/ch13-01-closures.md b/second-edition/src/ch13-01-closures.md index 50b8f33a8..e622c421f 100644 --- a/second-edition/src/ch13-01-closures.md +++ b/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: Filename: src/main.rs @@ -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 diff --git a/second-edition/src/ch13-02-iterators.md b/second-edition/src/ch13-02-iterators.md index 71d560446..c2729f92f 100644 --- a/second-edition/src/ch13-02-iterators.md +++ b/second-edition/src/ch13-02-iterators.md @@ -39,8 +39,7 @@ for val in v1_iter { } ``` -Listing 13-14: Making use of an iterator in a `for` -loop +Listing 13-14: Using an iterator in a `for` loop 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