Hey y’all! Mikey here, I wrote the words in question.
First off, I love this thread. The discussion in here is important and useful and extremely, extremely cool.
To weigh in on the question at hand, I consider the answer to be: yes, this is a typo. Indeed it should read “…returns a value of the associated type Iterator”. Thank you for catching this! We will fix it for the next printing.
To expand on the reasoning, I absolutely agree that protocols are types, even though they cannot be used in all of the same ways that structs and classes can. However, the type name following the associatedtype keyword in a protocol declaration is, conceptually, used in the same way that a generic type name like T is used in a generic function.
There are differences between associated types and generic placeholder types at the implementation level (which is why they have different syntax; I’d be happy to expand on that if you’re interested), but in our mental model, they serve the same purpose: to define a placeholder for some other concrete type (struct or class) that will be filled in by other code. In the case of this exercise, the StackIterator.
As with generic functions and data structures, we can apply a type constraint to an associatedtype, and here we do: we require that the Iterator placeholder must be filled in with a concrete type that conforms to IteratorProtocol.
But that is all side information. At the end of the day, we have declared an associatedtype placeholder called Iterator and that placeholder is substituted with your concrete type StackIterator at compile time, and compilation succeeds because the IteratorProtocol type constraint is satisfied.
So it is the Iterator type, or more exactly, your concrete type that substitutes Iterator at compile time (StackIterator), that the makeIterator() method must return in your implementation.
Does that help?