confusion as to which function was being referred to.
}
// Instead of writing out all the variants, we can also just import them all at once.
pub use self::SomethingOrNothing::*;
-//@ What this does is to define an entire family of types: We can now write
+//@ What this does is define an entire family of types: We can now write
//@ `SomethingOrNothing<i32>` to get back our `NumberOrNothing`.
type NumberOrNothing = SomethingOrNothing<i32>;
//@ However, we can also write `SomethingOrNothing<bool>` or even `SomethingOrNothing<SomethingOrNothing<i32>>`.
min.print();
}
-//@ If this printed `3`, then you generic `vec_min` is working! So get ready for the next part.
+//@ If this printed `3`, then your generic `vec_min` is working! So get ready for the next part.
// **Exercise 02.1**: Change your program such that it computes the minimum of a `Vec<f32>` (where `f32` is the type
// of 32-bit floating-point numbers). You should not change `vec_min` in any way, obviously!
}
// ## Cloning
-//@ If you have a close look at the type of `BigInt::from_vec`, you will notice that it
-//@ consumes the vector `v`. The caller hence loses access to its vector. There is however something
+//@ If you take a close look at the type of `BigInt::from_vec`, you will notice that it
+//@ consumes the vector `v`. The caller hence loses access to its vector. However, there is something
//@ we can do if we don't want that to happen: We can explicitly `clone` the vector,
//@ which means that a full (or *deep*) copy will be performed. Technically,
//@ `clone` takes a borrowed vector, and returns a fully owned one.
match *self { /*@*/
Nothing => Nothing, /*@*/
//@ In the second arm of the match, we need to talk about the value `v`
- //@ that's stored in `self`. However, if we would write the pattern as
+ //@ that's stored in `self`. However, if we were to write the pattern as
//@ `Something(v)`, that would indicate that we *own* `v` in the code
//@ after the arrow. That can't work though, we have to leave `v` owned by
//@ whoever called us - after all, we don't even own `self`, we just borrowed it.
//@ When analyzing the code of `rust_foo`, Rust has to assign a lifetime to `first`. It will choose the scope
//@ where `first` is valid, which is the entire rest of the function. Because `head` ties the lifetime of its
//@ argument and return value together, this means that `&v` also has to borrow `v` for the entire duration of
-//@ the function. So when we try to borrow `v` mutable for `push`, Rust complains that the two borrows (the one
+//@ the function `rust_foo`. So when we try to borrow `v` as mutable for `push`, Rust complains that the two borrows (the one
//@ for `head`, and the one for `push`) overlap. Lucky us! Rust caught our mistake and made sure we don't crash the program.
//@
//@ So, to sum this up: Lifetimes enable Rust to reason about *how long* a pointer has been borrowed. We can thus