Errata

Chapter 13 "Utility Traits" has following sentence:
"Vec<T> and [T: N] implement Borrow<[T]>."

I believe it should be `[T; N]` (semicolon instead of colon).

Note from the Author or Editor:
On page 320, in "Borrow and BorrowMut", we claim that "Vec<T> and [T: N] implement Borrow<[T]>."

The punctuation in "[T: N]" is incorrect. It should be "[T; N]", with a semicolon, not a colon.

let strings: Vec<String> = error_messages();

is not declared mutable. Later used as:

for rs in &mut strings { ......

the point at hand was clearly demonstrated. But minor error nevertheless

Note from the Author or Editor:
Naaol is correct. The last code block in the section should have an extra line, showing the vector declared as mut:

let mut strings = error_messages();
for rs in &mut strings { // the type of rs is &mut String
rs.push('\n'); // add a newline to each string
}

Current Copy
slice_a.swap(&mut slice_b)
Swaps the entire contents of slice_a and slice_b.
slice_a and slice_b must be the same length.

Suggested
slice_a.swap_with_slice(&mut slice_b)
Swaps the entire contents of slice_a and slice_b.
slice_a and slice_b must be the same length.

Note from the Author or Editor:
That's right: the name of the method that swaps the content of two slices is `swap_with_slice`, not `swap`. The error will be fixed for future printings.

The book says to add "-Z unstable-options --pretty expanded" to the rustc command line.

This used to work, but it doesn't anymore. The option is now spelled "-Z unstable-options -Z unpretty=expanded".

Alternatively, "cargo install cargo-expand" installs a new cargo subcommand that does this for you: "cargo expand".

Near the end of the section on doc-tests, the book says:

> If the code isn't even expected to compile, use `ignore` instead of `no_run`.

This is a mistake because "ignored" tests are only ignored by default. If you do `cargo test --ignored`, Cargo runs them all. The non-compiling code will then fail.

Probably the best thing to do is mark fake Rust code that isn't expected to compile as "text".

from the official documentation: docs.rs/string/latest/string/struct.String.html#impl-Borrow%3Cstr%3E

`String` actually implements `Borrow<str>`, not `Borrow<&str>`, and as “Borrow and BorrowMut” on page 316 also said it implemented `Borrow<str>`.

Note from the Author or Editor:
In explaining that `HashMap::get()` and friends are generic, the book incorrectly states that `String` implements `Borrow<&str>`. It actually implements `Borrow<str>`.

The paragraph describes the remaining chapters of the book but omits chapter 20 on asynchronous programming.

Note from the Author or Editor:
This has been fixed.

The crossbeam dependency is added with version constraint = "0.2", this leads to a compilation error, because the closure to spawner.spawn has 0 arguments in crossbeam 0.2, but the code is written for crossbeam 0.8 which expects 1 argument.

Note from the Author or Editor:
Fixed in current text.

There was three command line examples which displays the version of the new installed rust tools cargo, rustc and rustdoc.
All commands print out the version "1.49.0" released in Dec. 2020 but this version does not support the Rust edition 2021, it only support edition 2018. All examples in this book use edition 2021.
The first Rust version which support edition 2021 is 1.56. (2021-10-04).

Note from the Author or Editor:
Thomas is correct. The book is focused on Rust 1.56.0. Future printings of the Second Edition will reflect that here.

"Unlike C and C++, which require main to return zero if the program finished successfully, or a nonzero exit status if something went wrong, Rust assumes that if main returns at all, the program finished successfully."

This is in fact not required in C++, as per the C++ standard:

eel.is/c++draft/basic.start.main#5

Note from the Author or Editor:
It's true: although running off the end of any ordinary non-void function is undefined behavior in C++, running off the end of `main()` is specially permitted by the language standard.

We have changed the text to avoid the incorrect implication that returning from main is "required" in C++.

“401 BAD REQUEST” => “400 BAD REQUEST”

In the write_image fn, there's a call of encoder.encode with &pixels als the 1st param. pixels is already a slice, so no need to borrow (clippy::needless_borrow).

Note from the Author or Editor:
On page 33, in "Writing Image Files", in the code of `fn write_image`, we originally wrote `encoder.encode(&pixels, ...)`. The `&` is superfluous because `pixels` is already a reference.

The first argument should be simply `pixels`, not `&pixels`.

At page page 35, the book makes the user write `if args.len() != 5` in order to prevent the program from running in case the wrong amount of arguments is passed to the terminal.
Afterwards, at page 36, it asks the user to run `time .\target\release\mandelbrot mandel.png 4300x3000 -1.20,0.30 -1.0,0.20` to verify that the program is running correctly (and check how long it takes to run).

The issue is that - at least on Windows - when you use commas in the terminal, they are considered separators. This means that `time .\target\release\mandelbrot mandel1.png 4000x3000 -1.20,0.35 -1.0,0.20` gets separated as `[".\target\release\mandelbrot", "mandel.png", "4000x3000", "-1.20", "0.35" , "-1.0", "0.20"]` (length 7, hence not allowed) instead of being separated as `[".\target\release\mandelbrot", "mandel.png", "4000x3000", "-1.20,0.35" , "-1.0,0.20"]` (length 5).

My solution to this was simply to `':'` as a separator of the pairs, rather than `','`

Best,

Alex

Note from the Author or Editor:
The command shown in the book to run the Mandelbrot program does not work on Windows.

To run the program on Windows, start PowerShell and run the command like this:

measure-command { .\target\release\mandelbrot mandel.png 4000x3000 -1.20,0.35 -1,0.20 }

(Note: `Measure-Command` is the PowerShell equivalent of the `time` command in Unix shells. Comma characters are special in cmd.exe, but in PowerShell they are passed through to the Rust program as desired.)

When attempting to write the output, if an error occurs the message contains args.filename, which is the input file, not the output file.

match fs::write(&args.output, &data) {
Ok(_) => {},
Err(e) => {
eprintln!("{} failed to write to file '{}': {:?}", "Error:".red().bold(), args.filename, e);
std::process::exit(1);
}
};

should instead be

match fs::write(&args.output, &data) {
Ok(_) => {},
Err(e) => {
eprintln!("{} failed to write to file '{}': {:?}", "Error:".red().bold(), args.output, e);
std::process::exit(1);
}
};

Note from the Author or Editor:
On page 45, in the large code block showing `fn main`, there are two similar `eprintln!()` statements that report errors. Each one includes a filename in the error message, but the second prints the wrong filename.

The use of `args.filename` that appears after the call to `fs::write(&args.output, &data)` is incorrect. It should be `args.output` instead. We regret the error.

When attempting to write the output, if an error occurs the message contains args.filename, which is the input file, not the output file.

eprintln!("{} failed to write to file '{}': {:?}", "Error:".red().bold(), args.filename, e);

should instead be

eprintln!("{} failed to write to file '{}': {:?}", "Error:".red().bold(), args.output, e);

Note from the Author or Editor:
On page 47, the first line of the page mentions `args.filename`. This is the wrong filename. It should be `args.output` instead.

The book instructs the user to create a file via the echo command, using `echo "Hello, world" > test.txt`

When done in Windows (via cmd or PowerShell) this will result in the file getting a UTF-16 with BOM encoding.

Consequently, when running `cargo run "world" "Rust" test.txt test-modified.txt`, the program fails, with the error

```
error: failed to read from file '.\test.txt': Error { kind: InvalidData, message: "stream did not contain valid UTF-8" }
error: process didn't exit successfully: `target\debug\quickreplace.exe world Rust .\test.txt .\test-modified.txt` (exit code: 1)
```

The workaround is to create the file from outside the terminal.

Note from the Author or Editor:
We think the command will work on all new Windows machines since about May 2019. Older versions of cmd.exe and PowerShell default to UTF-16; newer versions default to UTF-8.

Creating the file with Notepad will certainly work. Another possible workaround is to use the PowerShell command `Set-Content -Path .\test.txt -Value 'Hello, world' -Encoding UTF8NoBOM`.

(Separately, in cmd.exe `ECHO "Hello, world" > file.txt` includes the quotes in the file. But at least that won't cause any trouble for Rust.)

Instead of
`cargo test -- --no-capture`
it should be
`cargo test -- --nocapture`

See `cargo test -- --help`

Note from the Author or Editor:
On page 196, the command-line option that causes Cargo not to capture test output is incorrect. We wrote "--no-capture". The correct option is "--nocapture". There is no hyphen between "no" and "capture".

At the very beginning of section: "Trait Object Layout"

Should the quoted text "In memory, a trait object is a fat pointer" be "In memory, a reference to trait object is a fat pointer"? I think that would be more accurate.

Note from the Author or Editor:
This is correct. At the time we wrote this, it was common to use "trait object" to refer to the reference itself, but the terminology has evolved over time and now "trait object" refers to the referent. We'll update the text in the next edition of the book.

The sentence says that `Creature` is a subtrait and supertrait of `Visible`, while the latter is the supertrait.

Note from the Author or Editor:
On page 270, in "Subtraits", we wrote: "...we say that `Creature` is a subtrait of `Visible`, and that `Creature` is `Visible`’s supertrait."

The second half of the sentence should say, "...and that `Visible` is `Creature`'s supertrait." We got it backwards.

The following is incorrect or requires more clarification since the `Box` is sized and makes it possible to invoke a method:

"...nor can you invoke a method on a `Box<dyn Write>`..."

Given the presented comparison between sized and unsized types, the correction would be:

"...nor can you invoke a method on a `dyn Write...`"

Note from the Author or Editor:
This remark is accurate. We've changed the text to say `dyn Write` rather than `Box<dyn Write>`.

The following text

> The deref and deref_mut methods take a &Self reference and return a
&Self::Target reference.

should be changed to

The deref method takes a &Self reference and returns a
&Self::Target reference, while deref_mut takes a &mut Self and returns a &mut Self::Target.

Note from the Author or Editor:
It's true, `Deref` uses shared references and `DerefMut` uses `mut` references. We will update the book.

"a closure is callable, but it's not a fn"

Suggested: "a closure is a callable, but it's not an fn if it captures from its environment"

Note from the Author or Editor:
In the chapter on closures, we wrote "a closure is callable, but it's not a `fn`." It should read "a closure is callable, but it's not necessarily a `fn`; a closure can be used as a `fn` only if it doesn't capture any variables."

Note that a closure that doesn't capture any variables still has its own type, distinct from all other `fn` types and closure types, as the subsequent text explains. But Rust lets you pass such a closure to places where a function pointer is expected, automatically converting the (zero-sized) closure to a (word-sized) function pointer.

While not a compile error, this line has an unnecessary ‘&’ reference:

Ok(sum + u64::from_str(&line?.trim())?)

This probably should be:

Ok(sum + u64::from_str(line?.trim())?)

Note from the Author or Editor:
Yes, the `&` in that line of code is superfluous and should be removed:

Ok(sum + u64::from_str(line?.trim())?)

It is no longer necessary to split the `io::stdin()` call from a `lock()` call, and likewise for `io::stdout(), io::stderr()`. The following compiles fine on the Rust playground:

```
use std::io::{stdin, BufRead};

fn main() {
let lines = stdin().lock().lines();
for line in lines {
println!("{}", line.unwrap())
}
}```

Note from the Author or Editor:
That's right, the paragraph about `io::stdin().lock()` not working is no longer correct. We've removed that paragraph and tightened up some example code that can take advantage of `io::stdin().lock()`.

On page 606, in Table 21-1, the last three rows of the table are incorrect.

We listed `$( ... ),?` and `$( ... );?` as matching "0 or 1 times, separated by commas" or semicolons. Clearly that doesn't make sense. There is no such syntax in Rust. The last two rows of the table should be deleted.

The last remaining row, `$( ... )?`, should be labeled "Match 0 or 1 times" (deleting the words "with no separator").

Thanks to Sofiane Akermoun for reporting this issue.