diff --git a/src/ch13-03-improving-our-io-project.md b/src/ch13-03-improving-our-io-project.md
index 2f5d6cdc68..9af0affb99 100644
--- a/src/ch13-03-improving-our-io-project.md
+++ b/src/ch13-03-improving-our-io-project.md
@@ -3,15 +3,15 @@
With this new knowledge about iterators, we can improve the I/O project in
Chapter 12 by using iterators to make places in the code clearer and more
concise. Let’s look at how iterators can improve our implementation of the
-`Config::new` function and the `search` function.
+`Config::build` function and the `search` function.
### Removing a `clone` Using an Iterator
In Listing 12-6, we added code that took a slice of `String` values and created
an instance of the `Config` struct by indexing into the slice and cloning the
values, allowing the `Config` struct to own those values. In Listing 13-17,
-we’ve reproduced the implementation of the `Config::new` function as it was in
-Listing 12-23:
+we’ve reproduced the implementation of the `Config::build` function as it was
+in Listing 12-23:
Filename: src/lib.rs
@@ -19,24 +19,24 @@ Listing 12-23:
{{#rustdoc_include ../listings/ch13-functional-features/listing-12-23-reproduced/src/lib.rs:ch13}}
```
-Listing 13-17: Reproduction of the `Config::new` function
-from Listing 12-23
+Listing 13-17: Reproduction of the `Config::build`
+function from Listing 12-23
At the time, we said not to worry about the inefficient `clone` calls because
we would remove them in the future. Well, that time is now!
We needed `clone` here because we have a slice with `String` elements in the
-parameter `args`, but the `new` function doesn’t own `args`. To return
+parameter `args`, but the `build` function doesn’t own `args`. To return
ownership of a `Config` instance, we had to clone the values from the `query`
and `filename` fields of `Config` so the `Config` instance can own its values.
-With our new knowledge about iterators, we can change the `new` function to
+With our new knowledge about iterators, we can change the `build` function to
take ownership of an iterator as its argument instead of borrowing a slice.
We’ll use the iterator functionality instead of the code that checks the length
of the slice and indexes into specific locations. This will clarify what the
-`Config::new` function is doing because the iterator will access the values.
+`Config::build` function is doing because the iterator will access the values.
-Once `Config::new` takes ownership of the iterator and stops using indexing
+Once `Config::build` takes ownership of the iterator and stops using indexing
operations that borrow, we can move the `String` values from the iterator into
`Config` rather than calling `clone` and making a new allocation.
@@ -51,7 +51,7 @@ Open your I/O project’s *src/main.rs* file, which should look like this:
```
We’ll change the start of the `main` function that we had in Listing 12-24 to
-the code in Listing 13-18. This won’t compile until we update `Config::new` as
+the code in Listing 13-18. This won’t compile until we update `Config::build` as
well.
Filename: src/main.rs
@@ -61,17 +61,17 @@ well.
```
Listing 13-18: Passing the return value of `env::args` to
-`Config::new`
+`Config::build`
The `env::args` function returns an iterator! Rather than collecting the
-iterator values into a vector and then passing a slice to `Config::new`, now
+iterator values into a vector and then passing a slice to `Config::build`, now
we’re passing ownership of the iterator returned from `env::args` to
-`Config::new` directly.
+`Config::build` directly.
-Next, we need to update the definition of `Config::new`. In your I/O project’s
-*src/lib.rs* file, let’s change the signature of `Config::new` to look like
-Listing 13-19. This still won’t compile because we need to update the function
-body.
+Next, we need to update the definition of `Config::build`. In your I/O
+project’s *src/lib.rs* file, let’s change the signature of `Config::build` to
+look like Listing 13-19. This still won’t compile because we need to update the
+function body.
Filename: src/lib.rs
@@ -79,14 +79,14 @@ body.
{{#rustdoc_include ../listings/ch13-functional-features/listing-13-19/src/lib.rs:here}}
```
-Listing 13-19: Updating the signature of `Config::new` to
-expect an iterator
+Listing 13-19: Updating the signature of `Config::build`
+to expect an iterator
The standard library documentation for the `env::args` function shows that the
type of the iterator it returns is `std::env::Args`, and that type implements
the `Iterator` trait and returns `String` values.
-We’ve updated the signature of the `Config::new` function so the parameter
+We’ve updated the signature of the `Config::build` function so the parameter
`args` has a generic type with the trait bounds `impl Iterator- `
instead of `&[String]`. This usage of the `impl Trait` syntax we discussed in
the [“Traits as Parameters”][impl-trait] section of Chapter 10
@@ -99,7 +99,7 @@ iterating over it, we can add the `mut` keyword into the specification of the
#### Using `Iterator` Trait Methods Instead of Indexing
-Next, we’ll fix the body of `Config::new`. Because `args` implements the
+Next, we’ll fix the body of `Config::build`. Because `args` implements the
`Iterator` trait, we know we can call the `next` method on it! Listing 13-20
updates the code from Listing 12-23 to use the `next` method:
@@ -109,7 +109,7 @@ updates the code from Listing 12-23 to use the `next` method:
{{#rustdoc_include ../listings/ch13-functional-features/listing-13-20/src/lib.rs:here}}
```
-Listing 13-20: Changing the body of `Config::new` to use
+Listing 13-20: Changing the body of `Config::build` to use
iterator methods
Remember that the first value in the return value of `env::args` is the name of
diff --git a/src/ch20-02-multithreaded.md b/src/ch20-02-multithreaded.md
index a348df12bd..3c1cc5bea5 100644
--- a/src/ch20-02-multithreaded.md
+++ b/src/ch20-02-multithreaded.md
@@ -301,9 +301,9 @@ Chapter 14. Try running `cargo doc --open` and clicking the `ThreadPool` struct
to see what the generated docs for `new` look like!
Instead of adding the `assert!` macro as we’ve done here, we could make `new`
-return a `Result` like we did with `Config::new` in the I/O project in Listing
-12-9. But we’ve decided in this case that trying to create a thread pool
-without any threads should be an unrecoverable error. If you’re feeling
+return a `Result` like we did with `Config::build` in the I/O project in
+Listing 12-9. But we’ve decided in this case that trying to create a thread
+pool without any threads should be an unrecoverable error. If you’re feeling
ambitious, try to write a version of `new` with the following signature to
compare both versions: