borrowing: replace Health Statistics with more exciting exercise

[mgeisler]

I have to admit that I was never a fan of the Health Statistics exercise: the theme is a little dull. However, we already have some examples here and there which vaguely use a computer game theme (PlayerInventory, PlayerMove).

So this PR replaces the Health Statistics exercise with a new and much more playful and exciting Wizard's Inventory exercise.

The new exercise improves the pedagogical flow by isolating the concepts of ownership transfer (moving data) and borrowing (referencing data): The previous exercise used the 'a lifetime syntax which has not been mentioned at this point!

This also removes the only reference to Rust on Exercism, so the third-party directly has been cleaned up.

[djmitche]

This doesn't seem to address borrowing very deeply -- there's borrowing going on in the cast_spell method but it's all implicit (spell_option is Option<&Spell>). That said, the old exercise didn't do any better, so this is an improvement!

As an example drawn from the iterator-invalidation example, what if a spell has some kind of invocation count and when that reaches zero, it is removed from the list of spells? Maybe it's possible to write a cast_spell method that does not pass the borrow checker, and ask students to fix it?

[mgeisler]

Hey @djmitche, thanks for looking!

This doesn't seem to address borrowing very deeply -- there's borrowing going on in the cast_spell method but it's all implicit (spell_option is Option<&Spell>). That said, the old exercise didn't do any better, so this is an improvement!

Yeah, you're right... I tested this exercise today and the feeling was that it was much easier than the previous one about the filter ligger and the binary trees.

In general, I've seen people really struggling to get started with the exercises. I think they might be too open ended... Not sure.

If this exercise is better than the status quo, then perhaps we can merge it (after I fix the double include of the test module) and iterate on it? I'll teach another class at the end of February, so I'll be revisiting the material then.

As an example drawn from the iterator-invalidation example, what if a spell has some kind of invocation count and when that reaches zero, it is removed from the list of spells?

That could be fun!

Maybe it's possible to write a cast_spell method that does not pass the borrow checker, and ask students to fix it?

I wonder how that would feel for the students... If it's just a matter of adding/removing an & then they don't get to type much Rust. If there are multiple things wrong, then I wonder if they'll know what to change and what to leave as-is.

I find it hard to guide people in the right direction while avoiding making things trivial.

[djmitche]

I think merging this as a monotonic improvement is fine!

[mgeisler]

what if a spell has some kind of invocation count and when that reaches zero, it is removed from the list of spells?

That is a great idea and I've now implemented this. I think that'll be a nice little challenge and prepare people for the talk about the borrow checker.

[mgeisler]

I think merging this as a monotonic improvement is fine!

Thanks! I'll have to return to this at some point and see if I can shuffle the exercises to have a more gradual progression in difficulty.