Errata Confirmed in 3rd Edition

Here are the confirmed errata for the 3rd edition’s first printing.
This post will be updated as errata are found.
Feel free to reply to this thread with any that you feel should be included.

Sets

  • p120: The penultimate paragraph begins “You can also go the other way, creating a set from an array using…”. This should read the other way around, “You can also go the other way, creating an array from a set using…”

Generics

  • Listing 21.6 & Listing 21.8: Both of these listings erroneously refer to the passed-in function as f, rather than its actual name, txform. In both listings, f(item) should be txform(item).

There’s another error in Sets: “You have arrays. No problem! Create two new arrays by initializing them with your sets:” should be “You have arrays. No problem! Create two new sets by initializing them with your arrays:” (I’m using the ebook so I don’t have page numbers.)

That’s on page 119, just before listing 11.11.

1 Like

I think I found a error as well. In Chapter 6, Loops, between Listing 6.1 and Figure 6.1, the 5th paragraph reads:
“Notice that i is not declared to be of the Int type. It could be, as in for i: Int in 1…5, but an explicit type declaration is not necessary. The type of i is inferred from its context (as is the let). In this example, i is inferred to be of type Int because the specified range contains integers.”

The let command is not inferred, the var command is inferred, as i is a variable, not a constant. I also tested by placing it in the for-in Loop, and got the following error:
“error: ‘let’ pattern cannot appear nested in an already immutable context
for let i in 1…5 {”

@lotsevenk

The two paragraphs before the paragraph that you quoted read as follows (bold text is mine):

The for keyword signals that you are writing a loop. You next declare an iterator called i that represents the current iteration of the loop. The iterator is constant within the body of the loop and only exists here; it is also managed for you by the compiler.

In the first iteration of the loop, its value is the first value in the range of the loop. Because you used ... to create an inclusive range of 1 through 5, the first value of i is 1. In the second iteration, the value of i is 2, and so on. You can think of i as being replaced with a new constant set to the next value in the range at the beginning of each iteration.

I think what is meant here is that i is treated as a constant by the loop when it executes. So that’s probably what is meant by “as is the let”. It means that i is a constant, so it’s as if it was created using the let keyword rather than the var keyword.

I think that it would be natural to assume that i is a variable rather than a constant because we think of i as changing each time the loop runs. And we all know that normally constants cannot change but variables can. But I suspect that the compiler implements things in a way that the loop runs like we have come to expect, despite i being treated as a constant.

I’m making some guesses here, but that is my interpretation based on the two paragraphs I quoted.

There’s a minor typo near the end of chapter 18, final paragraph of the Failable Initializers > A failable Town initializer section:

“…you will move back to Swift playgrounds to focus on a some specific language features.” → “…you will move back to Swift playgrounds to focus on some specific language features.”

The Kindle version appears to be missing a paragraph, or something’s out of order, in chapter 18 (I don’t know if the print version has the same issue) immediately following “Listing 18.5 Getting a reference to an employee” and its code.

No mention is made of changing the value of either erika or theBoss, but the subsequent sentence reads “Oh no! Anika’s employee ID is 16, not 0.” Which suggests that instructions are missing for assigning 16 as the value for theBoss.id and then observing what the value of anita.id becomes.

The print version is the same. I don’t think there’s anything missing, I think it’s trying to say that the code is wrong because Anika’s id should be 16 & the code isn’t setting her id to the correct value. But when you fix that in listing 18.6 it changes more than just Anika’s id.

This isn’t a typo, but it may have occurred due to a reordering of chapters from an earlier edition/draft.

In chapter 27 under the Retrieving Command-Line Arguments section, the reader is instructed to “Find the scheme editor control in the Xcode toolbar and click on its lefthand component, pictured in Figure 27.5.”

However, Figure 27.5 only shows the pop-up menu, not the location of the scheme editor. This doesn’t appear until chapter 28, Figure 28.3, under the Getting Started with TahDoodle section. Additionally, it’s referred to in 28.3 as the “Scheme Selector.”

The uses of editor/selector aren’t very confusing, but I was completely baffled in ch 27 as to where the scheme editor was. I ultimately managed to find it in the Product menu of Xcode using the Help menu’s search field. After a text search in the Kindle app, I managed to find “scheme”'s other appearances in the book and found the figure in ch 28.

Typo in chapter 28, between Listing 28.22 and Listing 28.23:

“Both the text field and the button’s action closure will need the newTaskTitle: The text field will update this string…”

Either the colon should be a period ("…will need the newTaskTitle. The text field…") or the T that follows the colon should be lowercase ("…will need the newTaskTile: the text field…").

On p. 292, Listing 21.6, change “result.append(f(item))” to “result.append(reform(item))”.

On p. 294 in the output of the “print()” calls, remove these lines which are not output:
Optional(“another string”)
[3, 3, 5]

On p. 389, change the first line in the initializer to
storage = max(min(wrappedValue, upperBound), 0).
The change is to replace 1 with upperBound.

There are a couple more that I didn’t see listed:

Listing 21.11 on page 295 is missing a closing parenthesis:
print(checkIfEqual(intStack, doubleStack))

Listing 21.12 on page 296 has the same issue, but since it is now struck out, it probably doesn’t matter
print(checkIfEqual(intStack, doubleStack))