Instead of having to explain why
```rs
let mut x = 100;
let y = &mut x;
let mut z_owned = *y;
let z = &mut z_owned;
*y += 100;
*z += 1000;
```
and
```rs
let mut x = 100;
let y = &mut x;
let z = &mut *y;
*y += 100;
*z += 1000;
```
are different, you still get the point across about having only one mutable reference.
As it stands, this exercise does too much (dereferencing and having only one mutable reference), and by doing so confuses people.
Example of someone being confused by this:
<https://discord.com/channels/273534239310479360/273541522815713281/872689531428692040>
Remove the use of trait objects as errors from `from_str` and
`try_from_into`; they seem to have caused a lot of confusion in
practice. (Also, it's considered best practice to use custom error
types instead of boxed errors in library code.) Instead, use custom
error enums, and update hints accordingly. Hints also provide
some guidance about converting errors, which could be covered
more completely in a future advanced errors section.
Also move from_str to directly after the similar exercise `from_into`,
for the sake of familiarity when solving.
Adjust error text and naming to conform with best practices.
Use `map_err()` instead of `or()`. Wrap lower-level errors instead of
ignoring their details.
Also, don't "cheat" by bypassing the `new()` function in tests.
Fix a dangling reference in the try_from_into hints.
Add new exercises errors5 and errors6, to introduce boxed errors and
custom error enums more gently. Delete errorsn, because it tried to do
too much too soon.
Improve the hints for move_semantics5, as well as the explanatory
comments in the code.
Previously, it was not clear what possible changes were allowed.
It seems that reordering the statements might be the intended solution.
The previous comment about not "adding newlines" doesn't make sense,
so treating it as "adding new lines" makes it more clear.
Renaming uninformative names like `optional_value`, `value`, `optional_values_vec` and `value` helps users distinguish between the two parts of the task.
The test description says "at least five types of fruit", but the test itself is checking for exactly five types of fruit, which was a bit misleading for newcomers like me :)
A simple change from "==" to ">=" should do the trick and successfully check for the "at least" condition.
