//@ 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
//@ 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
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>`.
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>() {
//@ 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
//@ `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