The existing test can be solved with the following:
```rs
while let Some(integer) = optional_integers.pop() {
assert_eq!(integer.unwrap(), range);
```
Similarly with `expect(...)`, `unwrap_or(0)`, `unwrap_or_default()`, etc. However, none of these solutions use the learning point of stacking `Option<T>`s.
The updated test can _only_ be solved by stacking `Option<T>`s:
```rs
while let Some(Some(integer)) = optional_integers.pop() {
assert_eq!(integer, cursor);
```
With the updated test, using `unwrap` or `expect` will panic when it hits the `None` value, and using `unwrap_or` or `unwrap_or_default` will cause the final `assert_eq!(cursor, 0)` to panic.
The `macros4.rs` challenge can automatically be solved by rustfmt without the user noticing.
Adding `#[rustfmt::skip]` above the `macro_rules!` line fixes this issue.
I changed the sentence that referenced the imperative implementation in iterators5.rs.
That implementation was already removed and replaced with `todo!()`
Following the discussion in #1195 this is the best I could come up with.
The issue for me (and apparently a few other learners) was that the code
needed to complete the exercise was not _missing_, but was rather there
but wrong.
In the end, what made the difference between this exercise and others
(for me) was that in this exercise I was supposed to learn what to
*expect* of an output. So I think it makes sense here to let the learner
modify the tests and not the code itself.
Fixes#1195
Signed-off-by: Daan Wynen <black.puppydog@gmx.de>
# Conflicts:
# info.toml
Missed a blank line, which causes the prompt incorrect like below:
```rust
You can keep working on this exercise,
or jump into the next one by removing the `I AM NOT DONE` comment:
6 | // Make this code compile by using the proper Rc primitives to express that the sun has multiple owners.
7 |
8 | // I AM NOT DONE
9 | use std::rc::Rc;
```
