small spelling/grammar errors

confusion as to which function was being referred to.

diff --git a/src/part02.rs b/src/part02.rs
index a01081b44ed1b0c0d74fc1365d5fc31b83c6e4ef..44a20d43408c92b15bd4ae675b71e16ca9eae2ef 100644 (file)
--- a/src/part02.rs
+++ b/src/part02.rs
@@ -17,7 +17,7 @@ pub enum SomethingOrNothing<T>  {
 }
 // Instead of writing out all the variants, we can also just import them all at once.
 pub use self::SomethingOrNothing::*;
 }
 // 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>>`.
 //@ `SomethingOrNothing<i32>` to get back our `NumberOrNothing`.
 type NumberOrNothing = SomethingOrNothing<i32>;
 //@ However, we can also write `SomethingOrNothing<bool>` or even `SomethingOrNothing<SomethingOrNothing<i32>>`.


@@ -141,7 +141,7 @@ pub fn main() {
     min.print();
 }
 
     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!
 
 // **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!

diff --git a/src/part05.rs b/src/part05.rs
index 6780ca306002e08a8b01312af83ecc7494dd4d4e..a0eb1d1530e5c54921af9e4bb627c9f418008eff 100644 (file)
--- a/src/part05.rs
+++ b/src/part05.rs
@@ -62,8 +62,8 @@ impl BigInt {
 }
 
 // ## Cloning
 }
 
 // ## 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.
 //@ 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.


@@ -99,7 +99,7 @@ impl<T: Clone> Clone for SomethingOrNothing<T> {
         match *self {                                               /*@*/
             Nothing => Nothing,                                     /*@*/
             //@ In the second arm of the match, we need to talk about the value `v`
         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.
             //@ `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.

diff --git a/src/part06.rs b/src/part06.rs
index a4ac7641e68a6063bb943717af498e483fa96056..5be00aa31eae4a4f3d9f51d30a42631309653784 100644 (file)
--- a/src/part06.rs
+++ b/src/part06.rs
@@ -137,7 +137,7 @@ fn rust_foo(mut v: Vec<i32>) -> i32 {
 //@ 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
 //@ 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
 //@ 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