I suppose I'll add another comment (that potentially applies to several of the exercises).

The rust compiler errors are great, but quite long and numerous. I like exercise that consist of making tests pass (very clear and well defined!) but if you start by running the tests without doing any implementation, you get screeds of errors.

More importantly, if you start implementing things to make one test at a time pass, it doesn't work, because the code won't compile. I've written in a lot of compiled languages, but most of my test-driven development experience is in Python, where this is less of a problem. Of course, it is true that Python won't work if you have syntax errors, but the nature of rust is that a lot of things that would be run-time errors in a language like Python are compile-time errors. Even compared to other compiled languages, Rust's emphasis on safety means that more things fail at compile time than is the case with other languages.

So what I do is to comment out all the tests first and (at least for this exercise) everything then compiles OK.

(I actually tried this first on the web routing exercise, which went particularly badly because the URLs include */, so the commenting out with /* ... */ didn't work, and it took me a while to understand why. I guess that was pretty unlucky.)

Anyway, I'm not sure I'm recommending that you supply the code with the tests commented out, but I wonder if you should supply it with only the first one active and the others deactivate with #[ignore]. Obviously, you'd need to tell people to unignore the tests, but they could do them one at a time, which might be less overwhelming and (more importantly) allows you to do the implementation bit-by-bit.

But of course, #[ignore] doesn't help enough because of exactly what I was talking about before: things that won't compile are still a problem. It would would need to be something that made the compiler ignore the code...which is probably back to commenting out, which doesn't feel great. So maybe this idea about the tests isn't really helpful.

Maybe you just want to suggest people comment all the tests out after the first and gradually uncomment them (moving the /* down) as they implement things.

See #1340 for the suggestion to comment out tests.

I liked this exercise, but failed on the iterator bit. (I got everything else.)

In your model solution you use

pub fn iter(&self) -> impl Iterator<Item = &Point> {
        self.points.iter()
}

but it seem to me this would have been very hard to figure out. I guess 25.5 does talk about impl return values, but even reading it again, it isn't clear to me that this is telling me I can implement a trait in this way. I thought it was just saying you can use impl on the left to specify a type that implements a trait and on the right to say that the return value is that same type. Or something.

Anyway, I might just be being slow, but I suspect a lot of people will struggle to solve this bit of the exercise. (Mind you, I'm just reading the course myself; maybe an instructor is supposed to flesh this stuff out.)

As an instructor, this sounds to me like "normal struggle" to understand the concept.

The snippet above isn't quite "implementing Iterator", it's just returning a type that implements Iterator. The -> impl Iterator<..> syntax means exactly that: this function returns a type that implements Iterator. It is a sort of shorthand that avoids having to write out the specific type, and with this syntax the caller can only assume that it gets a type implementing Iterator. But when compiled, the compiler figures out the specific type and compiles the code as if that type was given.

In this particular case, the specific type is std::slice::Iter, as that's the return type of self.points.iter().

... except that captain!