From d2c3027af89b9abb022fbb79f3203abb70ee9ea5 Mon Sep 17 00:00:00 2001 From: "Carol (Nichols || Goulding)" Date: Fri, 3 Jun 2022 16:07:23 -0400 Subject: [PATCH] Update references to ch12 to be Config::build instead of new --- src/ch13-03-improving-our-io-project.md | 44 ++++++++++++------------- src/ch20-02-multithreaded.md | 6 ++-- 2 files changed, 25 insertions(+), 25 deletions(-) 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: