diff --git a/ci/dictionary.txt b/ci/dictionary.txt index 6329ed1238..e2f5f670f0 100644 --- a/ci/dictionary.txt +++ b/ci/dictionary.txt @@ -2,8 +2,6 @@ personal_ws-1.1 en 0 utf-8 abcabcabc abcd abcdefghijklmnopqrstuvwxyz -adaptor -adaptors AddAssign Addr adfb diff --git a/src/ch13-02-iterators.md b/src/ch13-02-iterators.md index c99fcd6998..4ce9170de0 100644 --- a/src/ch13-02-iterators.md +++ b/src/ch13-02-iterators.md @@ -111,7 +111,7 @@ trait. Some of these methods call the `next` method in their definition, which is why you’re required to implement the `next` method when implementing the `Iterator` trait. -Methods that call `next` are called *consuming adaptors*, because calling them +Methods that call `next` are called *consuming adapters*, because calling them uses up the iterator. One example is the `sum` method, which takes ownership of the iterator and iterates through the items by repeatedly calling `next`, thus consuming the iterator. As it iterates through, it adds each item to a running @@ -131,17 +131,17 @@ ownership of the iterator we call it on. ### Methods that Produce Other Iterators -*Iterator adaptors* are methods defined on the `Iterator` trait that don’t +*Iterator adapters* are methods defined on the `Iterator` trait that don’t consume the iterator. Instead, they produce different iterators by changing some aspect of the original iterator. -Listing 13-14 shows an example of calling the iterator adaptor method `map`, +Listing 13-14 shows an example of calling the iterator adapter method `map`, which takes a closure to call on each item as the items are iterated through. The `map` method returns a new iterator that produces the modified items. The closure here creates a new iterator in which each item from the vector will be incremented by 1: -+ ```rust,not_desired_behavior {{#rustdoc_include ../listings/ch13-functional-features/listing-13-14/src/main.rs:here}} @@ -156,7 +156,7 @@ However, this code produces a warning: ``` The code in Listing 13-14 doesn’t do anything; the closure we’ve specified -never gets called. The warning reminds us why: iterator adaptors are lazy, and +never gets called. The warning reminds us why: iterator adapters are lazy, and we need to consume the iterator here. To fix this warning and consume the iterator, we’ll use the `collect` method, @@ -181,9 +181,9 @@ on each item. This is a great example of how closures let you customize some behavior while reusing the iteration behavior that the `Iterator` trait provides. -You can chain multiple calls to iterator adaptors to perform complex actions in +You can chain multiple calls to iterator adapters to perform complex actions in a readable way. But because all iterators are lazy, you have to call one of the -consuming adaptor methods to get results from calls to iterator adaptors. +consuming adapter methods to get results from calls to iterator adapters. ### Using Closures that Capture Their Environment diff --git a/src/ch13-03-improving-our-io-project.md b/src/ch13-03-improving-our-io-project.md index 4c1a508458..c560bc1124 100644 --- a/src/ch13-03-improving-our-io-project.md +++ b/src/ch13-03-improving-our-io-project.md @@ -116,7 +116,7 @@ value we want to put in the `query` field of `Config`. If `next` returns a not enough arguments were given and we return early with an `Err` value. We do the same thing for the `file_path` value. -### Making Code Clearer with Iterator Adaptors +### Making Code Clearer with Iterator Adapters We can also take advantage of iterators in the `search` function in our I/O project, which is reproduced here in Listing 13-21 as it was in Listing 12-19: @@ -129,14 +129,14 @@ project, which is reproduced here in Listing 13-21 as it was in Listing 12-19: -We can write this code in a more concise way using iterator adaptor methods. +We can write this code in a more concise way using iterator adapter methods. Doing so also lets us avoid having a mutable intermediate `results` vector. The functional programming style prefers to minimize the amount of mutable state to make code clearer. Removing the mutable state might enable a future enhancement to make searching happen in parallel, because we wouldn’t have to manage concurrent access to the `results` vector. Listing 13-22 shows this change: -+ ```rust,ignore {{#rustdoc_include ../listings/ch13-functional-features/listing-13-22/src/lib.rs:here}} @@ -146,7 +146,7 @@ concurrent access to the `results` vector. Listing 13-22 shows this change: Recall that the purpose of the `search` function is to return all lines in `contents` that contain the `query`. Similar to the `filter` example in Listing -13-16, this code uses the `filter` adaptor to keep only the lines that +13-16, this code uses the `filter` adapter to keep only the lines that `line.contains(query)` returns `true` for. We then collect the matching lines into another vector with `collect`. Much simpler! Feel free to make the same change to use iterator methods in the `search_case_insensitive` function as @@ -158,7 +158,7 @@ The next logical question is which style you should choose in your own code and why: the original implementation in Listing 13-21 or the version using iterators in Listing 13-22. Most Rust programmers prefer to use the iterator style. It’s a bit tougher to get the hang of at first, but once you get a feel -for the various iterator adaptors and what they do, iterators can be easier to +for the various iterator adapters and what they do, iterators can be easier to understand. Instead of fiddling with the various bits of looping and building new vectors, the code focuses on the high-level objective of the loop. This abstracts away some of the commonplace code so it’s easier to see the concepts diff --git a/src/ch13-04-performance.md b/src/ch13-04-performance.md index 5d09bf2940..0dbc7420a0 100644 --- a/src/ch13-04-performance.md +++ b/src/ch13-04-performance.md @@ -65,7 +65,7 @@ multiply the values together, sum all the results, and shift the bits in the sum `qlp_shift` bits to the right. Calculations in applications like audio decoders often prioritize performance -most highly. Here, we’re creating an iterator, using two adaptors, and then +most highly. Here, we’re creating an iterator, using two adapters, and then consuming the value. What assembly code would this Rust code compile to? Well, as of this writing, it compiles down to the same assembly you’d write by hand. There’s no loop at all corresponding to the iteration over the values in