//@ concurrently, that also reads from standard input? The result would be a mess. Hence
//@ Rust requires us to `lock` standard input if we want to perform large operations on
//@ it. (See [the documentation](https://doc.rust-lang.org/stable/std/io/struct.Stdin.html) for
- //@ more details.)
+ //@ more details.)
for line in stdin.lock().lines() {
// Rust's type for (dynamic, growable) strings is `String`. However, our variable `line`
// here is not yet of that type: It has type `io::Result<String>`.
//@ the return type of the function), but that's a bit too much magic for my taste. We are
//@ being more explicit here: `parse::<i32>` is `parse` with its generic type set to `i32`.
match line.trim().parse::<i32>() {
-
//@ `parse` returns again a `Result`, and this time we use a `match` to handle errors
//@ (like, the user entering something that is not a number).
//@ This is a common pattern in Rust: Operations that could go wrong will return
// **Exercise 03.1**: Define a trait `Print` to write a generic version of
// `SomethingOrNothing::print`.
-// Implement that trait for `i32`, and change the code above to use it.
+// Implement that trait for `i32`, and change `main` above to use the new generic `print` function.
// I will again provide a skeleton for this solution. It also shows how to attach bounds to generic
// implementations (just compare it to the `impl` block from the previous exercise).
// You can read this as "For all types `T` satisfying the `Print` trait, I provide an implementation