complete part 09

diff --git a/src/main.rs b/src/main.rs
index 27ad38e82bd5d4f96c97a3c3ab9ac0ecf54f1a57..ba75223f718e14d8c4bcd5eb348c260cf9ba9f60 100644 (file)
--- a/src/main.rs
+++ b/src/main.rs
@@ -76,6 +76,7 @@
 // * [Part 06: Copy, Lifetimes](part06.html)
 // * [Part 07: Operator Overloading, Tests, Formating](part07.html)
 // * [Part 08: Associated Types, Modules](part08.html)
 // * [Part 06: Copy, Lifetimes](part06.html)
 // * [Part 07: Operator Overloading, Tests, Formating](part07.html)
 // * [Part 08: Associated Types, Modules](part08.html)

+// * [Part 09: Iterators](part08.html)

 // * (to be continued)
 #![allow(dead_code, unused_imports, unused_variables, unused_mut)]
 mod part00;
 // * (to be continued)
 #![allow(dead_code, unused_imports, unused_variables, unused_mut)]
 mod part00;

diff --git a/src/part03.rs b/src/part03.rs
index d8d71b12cc138b95a477717f3a19d002b3513a5e..ef8ab927112b5aaf2b0a8cd1678d3be03b747d1a 100644 (file)
--- a/src/part03.rs
+++ b/src/part03.rs
@@ -22,13 +22,13 @@ use std::io;
 //@ specifying its type parameter doesn't tell us all that much.
 fn read_vec() -> Vec<i32> {
     let mut vec: Vec<i32> = Vec::<i32>::new();
 //@ specifying its type parameter doesn't tell us all that much.
 fn read_vec() -> Vec<i32> {
     let mut vec: Vec<i32> = Vec::<i32>::new();

-    // The central handle to the standard input is made available by `io::stdin()`.
+    // The central handle to the standard input is made available by the function `io::stdin`.

     let stdin = io::stdin();
     println!("Enter a list of numbers, one per line. End with Ctrl-D.");
     //@ We would now like to iterate over standard input line-by-line. We can use a `for` loop
     //@ for that, but there is a catch: What happens if there is some other piece of code running
     //@ concurrently, that also reads from standard input? The result would be a mess. Hence
     let stdin = io::stdin();
     println!("Enter a list of numbers, one per line. End with Ctrl-D.");
     //@ We would now like to iterate over standard input line-by-line. We can use a `for` loop
     //@ for that, but there is a catch: What happens if there is some other piece of code running
     //@ 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
+    //@ Rust requires us to `lock` standard input if we want to perform large operations on

     //@ it. (See [the documentation](http://doc.rust-lang.org/stable/std/io/struct.Stdin.html) for more
     //@ details.) 
     for line in stdin.lock().lines() {
     //@ it. (See [the documentation](http://doc.rust-lang.org/stable/std/io/struct.Stdin.html) for more
     //@ details.) 
     for line in stdin.lock().lines() {


@@ -40,17 +40,17 @@ fn read_vec() -> Vec<i32> {
         //@ You will see that `io::Result` is actually just an alias for `Result`, so click on that to obtain
         //@ the list of all constructors and methods of the type.
 
         //@ You will see that `io::Result` is actually just an alias for `Result`, so click on that to obtain
         //@ the list of all constructors and methods of the type.
 

-        //@ We will be lazy here and just assume that nothing goes wrong: `unwrap()` returns the `String` if there is one,
+        //@ We will be lazy here and just assume that nothing goes wrong: `unwrap` returns the `String` if there is one,

         //@ and panics the program otherwise. Since a `Result` carries some details about the error that occurred,
         //@ there will be a somewhat reasonable error message. Still, you would not want a user to see such
         //@ an error, so in a "real" program, we would have to do proper error handling.
         //@ and panics the program otherwise. Since a `Result` carries some details about the error that occurred,
         //@ there will be a somewhat reasonable error message. Still, you would not want a user to see such
         //@ an error, so in a "real" program, we would have to do proper error handling.

-        //@ Can you find the documentation of `Result::unwrap()`?
+        //@ Can you find the documentation of `Result::unwrap`?

         //@ 
         // I chose the same name (`line`) for the new variable to ensure that I will never, accidentally,
         // access the "old" `line` again.
         let line = line.unwrap();
         // Now that we have our `String`, we want to make it an `i32`.
         //@ 
         // I chose the same name (`line`) for the new variable to ensure that I will never, accidentally,
         // access the "old" `line` again.
         let line = line.unwrap();
         // Now that we have our `String`, we want to make it an `i32`.

-        //@ We first `trim()` the `line` to remove leading and trailing whitespace.
+        //@ We first `trim` the `line` to remove leading and trailing whitespace.

         //@ `parse` is a method on `String` that can convert a string to anything. Try finding it's documentation!
 
         //@ In this case, Rust *could* figure out automatically that we need an `i32` (because of the return type
         //@ `parse` is a method on `String` that can convert a string to anything. Try finding it's documentation!
 
         //@ In this case, Rust *could* figure out automatically that we need an `i32` (because of the return type


@@ -61,7 +61,7 @@ fn read_vec() -> Vec<i32> {
             //@ something that is not a number).
             //@ This is a common pattern in Rust: Operations that could go wrong will return `Option` or `Result`.
             //@ The only way to get to the value we are interested in is through pattern matching (and through helper functions
             //@ something that is not a number).
             //@ This is a common pattern in Rust: Operations that could go wrong will return `Option` or `Result`.
             //@ The only way to get to the value we are interested in is through pattern matching (and through helper functions

-            //@ like `unwrap()`). If we call a function that returns a `Result`, and throw the return value away,
+            //@ like `unwrap`). If we call a function that returns a `Result`, and throw the return value away,

             //@ the compiler will emit a warning. It is hence impossible for us to *forget* handling an error,
             //@ or to accidentally use a value that doesn't make any sense because there was an error producing it.
             Ok(num) => {
             //@ the compiler will emit a warning. It is hence impossible for us to *forget* handling an error,
             //@ or to accidentally use a value that doesn't make any sense because there was an error producing it.
             Ok(num) => {

diff --git a/src/part05.rs b/src/part05.rs
index b3b428ec03c67d65e155d1d33fa23d7d34594554..b593360122a7ba8beb277a494f2e3eb48c555056 100644 (file)
--- a/src/part05.rs
+++ b/src/part05.rs
@@ -21,7 +21,7 @@
 //@ `data` public - otherwise, the next parts of this course could not work on `BigInt`s. Of course, in a
 //@ real program, one would make the field private to ensure that the invariant (no trailing zeros) is maintained.
 pub struct BigInt {
 //@ `data` public - otherwise, the next parts of this course could not work on `BigInt`s. Of course, in a
 //@ real program, one would make the field private to ensure that the invariant (no trailing zeros) is maintained.
 pub struct BigInt {

-    pub data: Vec<u64>,
+    pub data: Vec<u64>, // least significant digit first, no trailing zeros

 }
 
 // Now that we fixed the data representation, we can start implementing methods on it.
 }
 
 // Now that we fixed the data representation, we can start implementing methods on it.


@@ -31,7 +31,7 @@ impl BigInt {
     //@ fields and initial values assigned to them.
     pub fn new(x: u64) -> Self {
         if x == 0 {
     //@ fields and initial values assigned to them.
     pub fn new(x: u64) -> Self {
         if x == 0 {

-            BigInt { data: vec![] }
+            BigInt { data: vec![] }                                 /*@*/

         } else {
             BigInt { data: vec![x] }                                /*@*/
         }
         } else {
             BigInt { data: vec![x] }                                /*@*/
         }


@@ -53,7 +53,7 @@ impl BigInt {
     // 
     // **Exercise 05.1**: Implement this function.
     // 
     // 
     // **Exercise 05.1**: Implement this function.
     // 

-    // *Hint*: You can use `pop()` to remove the last element of a vector.
+    // *Hint*: You can use `pop` to remove the last element of a vector.

     pub fn from_vec(mut v: Vec<u64>) -> Self {
         unimplemented!()
     }
     pub fn from_vec(mut v: Vec<u64>) -> Self {
         unimplemented!()
     }

diff --git a/src/part06.rs b/src/part06.rs
index b39a441f1a7c95bfce5af88d99b934b52cf4529e..5b90142825798a25321352f136b1c9c913d555a7 100644 (file)
--- a/src/part06.rs
+++ b/src/part06.rs
@@ -26,7 +26,7 @@ impl BigInt {
 }
 
 // Now we can write `vec_min`.
 }
 
 // Now we can write `vec_min`.

-//@ However, in order to make it type-check, we have to make a full (deep) copy of e by calling `clone()`.
+//@ However, in order to make it type-check, we have to make a full (deep) copy of e by calling `clone`.

 fn vec_min(v: &Vec<BigInt>) -> Option<BigInt> {
     let mut min: Option<BigInt> = None;
     for e in v {
 fn vec_min(v: &Vec<BigInt>) -> Option<BigInt> {
     let mut min: Option<BigInt> = None;
     for e in v {


@@ -48,7 +48,7 @@ fn vec_min(v: &Vec<BigInt>) -> Option<BigInt> {
 //@ `e.clone()`, Rust will complain "Cannot move out of borrowed content". That's because
 //@ `e` is a `&BigInt`. Assigning `min = Some(*e)` works just like a function call: Ownership of the
 //@ underlying data is transferred from where `e` borrows from to `min`. But that's not allowed, since
 //@ `e.clone()`, Rust will complain "Cannot move out of borrowed content". That's because
 //@ `e` is a `&BigInt`. Assigning `min = Some(*e)` works just like a function call: Ownership of the
 //@ underlying data is transferred from where `e` borrows from to `min`. But that's not allowed, since

-//@ we just borrowed `e`, so we cannot empty it! We can, however, call `clone()` on it. Then we own
+//@ we just borrowed `e`, so we cannot empty it! We can, however, call `clone` on it. Then we own

 //@ the copy that was created, and hence we can store it in `min`. <br/>
 //@ Of course, making such a full copy is expensive, so we'd like to avoid it. We'll some to that in the next part.
 
 //@ the copy that was created, and hence we can store it in `min`. <br/>
 //@ Of course, making such a full copy is expensive, so we'd like to avoid it. We'll some to that in the next part.
 


@@ -92,7 +92,7 @@ impl<T: Copy> Copy for SomethingOrNothing<T> {}
 //@ `Clone`. This makes the cost explicit.
 
 // ## Lifetimes
 //@ `Clone`. This makes the cost explicit.
 
 // ## Lifetimes

-//@ To fix the performance problems of `vec_min`, we need to avoid using `clone()`. We'd like
+//@ To fix the performance problems of `vec_min`, we need to avoid using `clone`. We'd like

 //@ the return value to not be owned (remember that this was the source of our need for cloning), but *borrowed*.
 
 //@ The function `head` demonstrates how that could work: It borrows the first element of a vector if it is non-empty.
 //@ the return value to not be owned (remember that this was the source of our need for cloning), but *borrowed*.
 
 //@ The function `head` demonstrates how that could work: It borrows the first element of a vector if it is non-empty.

diff --git a/src/part08.rs b/src/part08.rs
index 630da427dfec70d2dad9f1920579b2b4277faf8e..4ef9d742447e14d8e7a493a6a4bf24d2c9737d9d 100644 (file)
--- a/src/part08.rs
+++ b/src/part08.rs
@@ -145,4 +145,4 @@ mod tests {
 // **Exercise 08.6**: Write a subtraction function, and testcases for it. Decide for yourself how you want to handle negative results.
 // For example, you may want to return an `Option`, to panic, or to return `0`.
 
 // **Exercise 08.6**: Write a subtraction function, and testcases for it. Decide for yourself how you want to handle negative results.
 // For example, you may want to return an `Option`, to panic, or to return `0`.
 

-//@ [index](main.html) | [previous](part07.html) | [next](main.html)
+//@ [index](main.html) | [previous](part07.html) | [next](part09.html)

diff --git a/src/part09.rs b/src/part09.rs
index 63bab76a177aec6c49963477eecfcf06847c2d8a..c6c32a47b17292e38aa8920e270b8d6aba16dc27 100644 (file)
--- a/src/part09.rs
+++ b/src/part09.rs
@@ -1,27 +1,27 @@
-// Rust-101, Part 09: Iterators (WIP)
-// ==================================
+// Rust-101, Part 09: Iterators
+// ============================

 
 use part05::BigInt;
 
 
 use part05::BigInt;
 

-// In the following, we will look into the iterator mechanism of Rust and make our `BigInt` compatible
-// with the `for` loops. Of course, this is all about implementing particular traits again. In particular,
-// an iterator is something that implements the `Iterator` trait. As you can see in [the documentation](http://doc.rust-lang.org/beta/std/iter/trait.Iterator.html),
-// this trait mandates a single function `next` returning an `Option<Self::Item>`, where `Item` is an
-// associated type chosen by the implementation. (There are many more methods provided for `Iterator`,
-// but they all have default implementations, so we don't have to worry about them right now).
-// 
-// For the case of `BigInt`, we want our iterator to iterate over the digits in normal, notational order: The most-significant
-// digit comes first. So, we have to write down some type, and implement `Iterator` for it such that `next` returns the digits
-// one-by-one. Clearly, the iterator must somehow be able to access the number it iterates over, and it must store its current
-// location. However, it cannot *own* the `BigInt`, because then the number would be gone after iteration! That'd certainly be bad.
-// The only alternative is for the iterator to *borrow* the number.
+//@ In the following, we will look into the iterator mechanism of Rust and make our `BigInt` compatible
+//@ with the `for` loops. Of course, this is all about implementing certain traits again. In particular,
+//@ an iterator is something that implements the `Iterator` trait. As you can see in [the documentation](http://doc.rust-lang.org/beta/std/iter/trait.Iterator.html),
+//@ this trait mandates a single function `next` returning an `Option<Self::Item>`, where `Item` is an
+//@ associated type chosen by the implementation. (There are many more methods provided for `Iterator`,
+//@ but they all have default implementations, so we don't have to worry about them right now.)
+//@ 
+//@ For the case of `BigInt`, we want our iterator to iterate over the digits in normal, notational order: The most-significant
+//@ digit comes first. So, we have to write down some type, and implement `Iterator` for it such that `next` returns the digits
+//@ one-by-one. Clearly, the iterator must somehow be able to access the number it iterates over, and it must store its current
+//@ location. However, it cannot *own* the `BigInt`, because then the number would be gone after iteration! That'd certainly be bad.
+//@ The only alternative is for the iterator to *borrow* the number.

 
 

-// In writing this down, we again have to be explicit about the lifetime of the borrow: We can't just have an
-// `Iter`, we must have an `Iter<'a>` that borrowed the number for lifetime `'a`. This is our first example of
-// a datatype that's polymorphic in a lifetime, as opposed to a type. <br/>
-// `usize` here is the type of unsigned, pointer-sized numbers. It is typically the type of "lengths of things",
-// in particular, it is the type of the length of a `Vec` and hence the right type to store an offset into the vector of digits.
-struct Iter<'a> {
+//@ In writing this down, we again have to be explicit about the lifetime of the borrow: We can't just have an
+//@ `Iter`, we must have an `Iter<'a>` that borrows the number for lifetime `'a`. This is our first example of
+//@ a data-type that's polymorphic in a lifetime, as opposed to a type. <br/>
+//@ `usize` here is the type of unsigned, pointer-sized numbers. It is typically the type of "lengths of things",
+//@ in particular, it is the type of the length of a `Vec` and hence the right type to store an offset into the vector of digits.
+pub struct Iter<'a> {

     num: &'a BigInt,
     idx: usize, // the index of the last number that was returned
 }
     num: &'a BigInt,
     idx: usize, // the index of the last number that was returned
 }


@@ -34,10 +34,10 @@ impl<'a> Iterator for Iter<'a> {
     fn next(&mut self) -> Option<u64> {
         // First, check whether there's any more digits to return.
         if self.idx == 0 {
     fn next(&mut self) -> Option<u64> {
         // First, check whether there's any more digits to return.
         if self.idx == 0 {

-            // We already returned all the digits.
+            // We already returned all the digits, nothing to do.

             None                                                    /*@*/
         } else {
             None                                                    /*@*/
         } else {

-            // Decrement, and return next digit.
+            // Otherwise: Decrement, and return next digit.

             self.idx = self.idx - 1;                                /*@*/
             Some(self.num.data[self.idx])                           /*@*/
         }
             self.idx = self.idx - 1;                                /*@*/
             Some(self.num.data[self.idx])                           /*@*/
         }


@@ -46,9 +46,9 @@ impl<'a> Iterator for Iter<'a> {
 
 // All we need now is a function that creates such an iterator for a given `BigInt`.
 impl BigInt {
 
 // All we need now is a function that creates such an iterator for a given `BigInt`.
 impl BigInt {

-    // Notice that when we write the type of `iter`, we don't actually have to give the lifetime parameter of `Iter`. Just as it is
-    // the case with functions returning borrowed data, you can elide the lifetime. The rules for adding the lifetimes are exactly the
-    // same. (See the last section of [part 06](part06.html).)
+    //@ Notice that when we write the type of `iter`, we don't actually have to give the lifetime parameter of `Iter`. Just as it is
+    //@ the case with functions returning borrowed data, you can elide the lifetime. The rules for adding the lifetimes are exactly the
+    //@ same. (See the last section of [part 06](part06.html).)

     fn iter(&self) -> Iter {
         Iter { num: self, idx: self.data.len() }                    /*@*/
     }
     fn iter(&self) -> Iter {
         Iter { num: self, idx: self.data.len() }                    /*@*/
     }


@@ -65,37 +65,42 @@ pub fn main() {
 // Of course, we don't have to use `for` to apply the iterator. We can also explicitly call `next`.
 fn print_digits_v1(b: &BigInt) {
     let mut iter = b.iter();
 // Of course, we don't have to use `for` to apply the iterator. We can also explicitly call `next`.
 fn print_digits_v1(b: &BigInt) {
     let mut iter = b.iter();

-    // `loop` is the keyword for a loop without a condition: It runs endlessly, or until you break out of
-    // it with `break` or `return`.
+    //@ `loop` is the keyword for a loop without a condition: It runs endlessly, or until you break out of
+    //@ it with `break` or `return`.

     loop {
         // Each time we go through the loop, we analyze the next element presented by the iterator - until it stops.
     loop {
         // Each time we go through the loop, we analyze the next element presented by the iterator - until it stops.

-        match iter.next() {
-            None => break,
-            Some(digit) => println!("{}", digit)
-        }
+        match iter.next() {                                         /*@*/
+            None => break,                                          /*@*/
+            Some(digit) => println!("{}", digit)                    /*@*/
+        }                                                           /*@*/

     }
 }
 
     }
 }
 

-// Now, it turns out that this combination of doing a loop and a pattern matching is fairly common, and Rust
-// provides some convenient syntactic sugar for it.
+//@ Now, it turns out that this combination of doing a loop and a pattern matching is fairly common, and Rust
+//@ provides some convenient syntactic sugar for it.

 fn print_digits_v2(b: &BigInt) {
     let mut iter = b.iter();
 fn print_digits_v2(b: &BigInt) {
     let mut iter = b.iter();

-    // `while let` performs the given pattern matching on every round of the loop, and cancels the loop if the pattern
-    // doesn't match. There's also `if let`, which works similar, but of course without the loopy part.
+    //@ `while let` performs the given pattern matching on every round of the loop, and cancels the loop if the pattern
+    //@ doesn't match. There's also `if let`, which works similar, but of course without the loopy part.

     while let Some(digit) = iter.next() {
         println!("{}", digit)
     }
 }
 
     while let Some(digit) = iter.next() {
         println!("{}", digit)
     }
 }
 

-// ## Iterator invalidation and lifetimes
-// You may have been surprised that we had to explicitly annotate a lifetime when we wrote `Iter`. Of
-// course, with lifetimes being present at every borrow in Rust, this is only consistent. But do we at
-// least gain something from this extra annotation burden? (Thankfully, this burden only occurs when we
-// define *types*, and not when we define functions - which is typically much more common.)
+// **Exercise 09.1**: Write a testcase for the iterator, making sure it yields the corrects numbers.

 // 
 // 

-// It turns out that the answer to this question is yes! This particular aspect of the concept of
-// lifetimes helps Rust to eliminate the issue of *iterator invalidation*. Consider the following
-// piece of code.
+// **Exercise 09.2**: Write a function `iter_ldf` that iterators over the digits with the least-significant
+// digits coming first. Write a testcase for it.
+
+// ## Iterator invalidation and lifetimes
+//@ You may have been surprised that we had to explicitly annotate a lifetime when we wrote `Iter`. Of
+//@ course, with lifetimes being present at every borrow in Rust, this is only consistent. But do we at
+//@ least gain something from this extra annotation burden? (Thankfully, this burden only occurs when we
+//@ define *types*, and not when we define functions - which is typically much more common.)
+
+//@ It turns out that the answer to this question is yes! This particular aspect of the concept of
+//@ lifetimes helps Rust to eliminate the issue of *iterator invalidation*. Consider the following
+//@ piece of code.

 fn iter_invalidation_demo() {
     let mut b = BigInt::new(1 << 63) + BigInt::new(1 << 16) + BigInt::new(1 << 63);
     for digit in b.iter() {
 fn iter_invalidation_demo() {
     let mut b = BigInt::new(1 << 63) + BigInt::new(1 << 16) + BigInt::new(1 << 63);
     for digit in b.iter() {


@@ -103,23 +108,41 @@ fn iter_invalidation_demo() {
         /*b = b + BigInt::new(1);*/                                 /* BAD! */
     }
 }
         /*b = b + BigInt::new(1);*/                                 /* BAD! */
     }
 }

-// If you enable the bad line, Rust will reject the code. Why? The problem is that we are modifying the
-// number while iterating over it. In other languages, this can have all sorts of effects from inconsistent
-// data or throwing an exception (Java) to bad pointers being dereferenced (C++). Rust, however, is able to
-// detect this situation. When you call `iter`, you have to borrow `b` for some lifetime `'a`, and you obtain
-// `Iter<'a>`. This is an iterator that's only valid for lifetime `'a`. Gladly, we have this annotation available
-// to make such a statement. Now, since we are using the iterator throughout the loop, `'a` has to span the loop.
-// This `b` is borrowed for the duration of the loop, and we cannot mutate it. This is yet another example for
-// how the combination of mutation and aliasing leads to undesired effects (not necessarily crashes, like in Java),
-// which Rust successfully prevents.
-// 
-// Technically speaking, there's one more subtlety that I did not explain yet. We never explicitly tied the lifetime `'a` of the
-// iterator to the loop so how does this happen? The answer lies in the full type of `next()`:
-// `fn<'a, 'b>(&'b mut Iter<'a>) -> Option<u64>`. Since `next()` takes a *borrowed* iterator, there are two lifetimes involved:
-// The lifetime of the borrow of the iterator, and the lifetime of the iterator itself. In such a case of nested lifetimes,
-// Rust implicitly adds the additional constraint that the inner lifetime *outlives* the outer one: The borrow of an iterator
-// cannot be valid for longer than the iterator itself is valid. This means that the lifetime `'a` of the iterator needs
-// to outlive every call to `next()`, and hence the loop. Lucky enough, this all happens without our intervention.
+//@ If you enable the bad line, Rust will reject the code. Why? The problem is that we are modifying the
+//@ number while iterating over it. In other languages, this can have all sorts of effects from inconsistent
+//@ data or throwing an exception (Java) to bad pointers being dereferenced (C++). Rust, however, is able to
+//@ detect this situation. When you call `iter`, you have to borrow `b` for some lifetime `'a`, and you obtain
+//@ `Iter<'a>`. This is an iterator that's only valid for lifetime `'a`. Gladly, we have this annotation available
+//@ to make such a statement. Rust enforces that `'a` spans every call to `next`, which means it has to span the loop.
+//@ Thus `b` is borrowed for the duration of the loop, and we cannot mutate it. This is yet another example for
+//@ how the combination of mutation and aliasing leads to undesired effects (not necessarily crashes, think of Java),
+//@ which Rust successfully prevents.
+
+// ## Iterator conversion trait
+//@ If you closely compare the `for` loop in `main` above, with the one in `vec_min`, you will notice that we were able to write
+//@ `for e in v` earlier, but now we have to call `iter`. Why is that? Well, the `for` sugar is not actually tied to `Iterator`.
+//@ Instead, if demands an implementation of [`IntoIterator`](http://doc.rust-lang.org/beta/std/iter/trait.IntoIterator.html).
+//@ That's a trait of types that provide a *conversion* function into some kind of iterator. These conversion traits are a frequent
+//@ pattern in Rust: Rather than demanding that something is an iterator, or a string, or whatever; one demands that something
+//@ can be converted to an iterator/string/whatever. This provides convenience similar to overloading of functions: The function
+//@ can be called with lots of different types. By implementing such traits for your types, you can even make your own types
+//@ work smoothly with existing library functions. As usually for Rust, this abstraction comes at zero cost: If your data is already
+//@ of the right type, the conversion function will not do anything and trivially be optimized away.

 
 

+//@ If you have a look at the documentation of `IntoIterator`, you will notice that the function `into_iter` it provides actually
+//@ consumes its argument. So, we'd like to make `Self` a borrowed type, such that the number is not lost after the iteration.
+impl<'a> IntoIterator for &'a BigInt {
+    type Item = u64;
+    type IntoIter = Iter<'a>;
+    fn into_iter(self) -> Iter<'a> {
+        self.iter()
+    }
+}
+// With this in place, you can now replace `b.iter()` in `main` by `&b`. Go ahead and try it! <br/>
+//@ Wait, `&b`? Why that? Well, we implemented `IntoIterator` for `&BigInt`, so we have to borrow `b`. If we wanted to be able to write
+//@ just `b`, we'd have to also implement `IntoIterator` for `BigInt` - which, as already mentioned, would mean that `b` is actually consumed
+//@ by the iteration, and gone. This can easily happen, for example, with a `Vec`: Both `Vec` and `&Vec` implement `IntoIterator`, so if
+//@ you do `for e in v`, and `v` has type `Vec`, then you will obtain ownership of the elements during the iteration - and destroy the vector
+//@ in the process. We actually did that in `vec_min`, but we did not care. You can write `for e in &v` or `for e in v.iter()` to avoid this.

 
 //@ [index](main.html) | [previous](part08.html) | [next](main.html)
 
 //@ [index](main.html) | [previous](part08.html) | [next](main.html)

diff --git a/workspace/src/main.rs b/workspace/src/main.rs
index 09954a08726b580b5acc7d935d7d972c60f81841..4d6d2302672ecab5aacac82de2010982988ae6b0 100644 (file)
--- a/workspace/src/main.rs
+++ b/workspace/src/main.rs
@@ -10,6 +10,7 @@ mod part05;
 mod part06;
 mod part07;
 mod part08;
 mod part06;
 mod part07;
 mod part08;

+mod part09;

 
 // This decides which part is actually run.
 fn main() {
 
 // This decides which part is actually run.
 fn main() {

diff --git a/workspace/src/part03.rs b/workspace/src/part03.rs
index 5a5327c26962be4ea044de8d74afab0cc4377bff..152b5258a89fe513f6fe3e2d6d2ded2c31fee397 100644 (file)
--- a/workspace/src/part03.rs
+++ b/workspace/src/part03.rs
@@ -10,7 +10,7 @@ use std::io;
 
 fn read_vec() -> Vec<i32> {
     let mut vec: Vec<i32> = Vec::<i32>::new();
 
 fn read_vec() -> Vec<i32> {
     let mut vec: Vec<i32> = Vec::<i32>::new();

-    // The central handle to the standard input is made available by `io::stdin()`.
+    // The central handle to the standard input is made available by the function `io::stdin`.

     let stdin = io::stdin();
     println!("Enter a list of numbers, one per line. End with Ctrl-D.");
     for line in stdin.lock().lines() {
     let stdin = io::stdin();
     println!("Enter a list of numbers, one per line. End with Ctrl-D.");
     for line in stdin.lock().lines() {

diff --git a/workspace/src/part05.rs b/workspace/src/part05.rs
index f1c558720df94135f682ec0d191b1265db91b3ba..78113b7bb36e5e5acc1af45842f66e6de153ceb2 100644 (file)
--- a/workspace/src/part05.rs
+++ b/workspace/src/part05.rs
@@ -4,14 +4,14 @@
 // ## Big Numbers
 
 pub struct BigInt {
 // ## Big Numbers
 
 pub struct BigInt {

-    pub data: Vec<u64>,
+    pub data: Vec<u64>, // least significant digit first, no trailing zeros

 }
 
 // Now that we fixed the data representation, we can start implementing methods on it.
 impl BigInt {
     pub fn new(x: u64) -> Self {
         if x == 0 {
 }
 
 // Now that we fixed the data representation, we can start implementing methods on it.
 impl BigInt {
     pub fn new(x: u64) -> Self {
         if x == 0 {

-            BigInt { data: vec![] }
+            unimplemented!()

         } else {
             unimplemented!()
         }
         } else {
             unimplemented!()
         }


@@ -31,7 +31,7 @@ impl BigInt {
     // 
     // **Exercise 05.1**: Implement this function.
     // 
     // 
     // **Exercise 05.1**: Implement this function.
     // 

-    // *Hint*: You can use `pop()` to remove the last element of a vector.
+    // *Hint*: You can use `pop` to remove the last element of a vector.

     pub fn from_vec(mut v: Vec<u64>) -> Self {
         unimplemented!()
     }
     pub fn from_vec(mut v: Vec<u64>) -> Self {
         unimplemented!()
     }

diff --git a/workspace/src/part09.rs b/workspace/src/part09.rs
index 6b3f73782445e4e3cf912be78fcc07a7adf5c54b..61cc70b8ddb6b678030b4f57892717668ad36d55 100644 (file)
--- a/workspace/src/part09.rs
+++ b/workspace/src/part09.rs
@@ -1,27 +1,10 @@
-// Rust-101, Part 09: Iterators (WIP)
-// ==================================
+// Rust-101, Part 09: Iterators
+// ============================

 
 use part05::BigInt;
 
 
 use part05::BigInt;
 

-// In the following, we will look into the iterator mechanism of Rust and make our `BigInt` compatible
-// with the `for` loops. Of course, this is all about implementing particular traits again. In particular,
-// an iterator is something that implements the `Iterator` trait. As you can see in [the documentation](http://doc.rust-lang.org/beta/std/iter/trait.Iterator.html),
-// this trait mandates a single function `next` returning an `Option<Self::Item>`, where `Item` is an
-// associated type chosen by the implementation. (There are many more methods provided for `Iterator`,
-// but they all have default implementations, so we don't have to worry about them right now).
-// 
-// For the case of `BigInt`, we want our iterator to iterate over the digits in normal, notational order: The most-significant
-// digit comes first. So, we have to write down some type, and implement `Iterator` for it such that `next` returns the digits
-// one-by-one. Clearly, the iterator must somehow be able to access the number it iterates over, and it must store its current
-// location. However, it cannot *own* the `BigInt`, because then the number would be gone after iteration! That'd certainly be bad.
-// The only alternative is for the iterator to *borrow* the number.

 
 

-// In writing this down, we again have to be explicit about the lifetime of the borrow: We can't just have an
-// `Iter`, we must have an `Iter<'a>` that borrowed the number for lifetime `'a`. This is our first example of
-// a datatype that's polymorphic in a lifetime, as opposed to a type. <br/>
-// `usize` here is the type of unsigned, pointer-sized numbers. It is typically the type of "lengths of things",
-// in particular, it is the type of the length of a `Vec` and hence the right type to store an offset into the vector of digits.
-struct Iter<'a> {
+pub struct Iter<'a> {

     num: &'a BigInt,
     idx: usize, // the index of the last number that was returned
 }
     num: &'a BigInt,
     idx: usize, // the index of the last number that was returned
 }


@@ -34,10 +17,10 @@ impl<'a> Iterator for Iter<'a> {
     fn next(&mut self) -> Option<u64> {
         // First, check whether there's any more digits to return.
         if self.idx == 0 {
     fn next(&mut self) -> Option<u64> {
         // First, check whether there's any more digits to return.
         if self.idx == 0 {

-            // We already returned all the digits.
+            // We already returned all the digits, nothing to do.

             unimplemented!()
         } else {
             unimplemented!()
         } else {

-            // Decrement, and return next digit.
+            // Otherwise: Decrement, and return next digit.

             unimplemented!()
         }
     }
             unimplemented!()
         }
     }


@@ -45,9 +28,6 @@ impl<'a> Iterator for Iter<'a> {
 
 // All we need now is a function that creates such an iterator for a given `BigInt`.
 impl BigInt {
 
 // All we need now is a function that creates such an iterator for a given `BigInt`.
 impl BigInt {

-    // Notice that when we write the type of `iter`, we don't actually have to give the lifetime parameter of `Iter`. Just as it is
-    // the case with functions returning borrowed data, you can elide the lifetime. The rules for adding the lifetimes are exactly the
-    // same. (See the last section of [part 06](part06.html).)

     fn iter(&self) -> Iter {
         unimplemented!()
     }
     fn iter(&self) -> Iter {
         unimplemented!()
     }


@@ -64,37 +44,26 @@ pub fn main() {
 // Of course, we don't have to use `for` to apply the iterator. We can also explicitly call `next`.
 fn print_digits_v1(b: &BigInt) {
     let mut iter = b.iter();
 // Of course, we don't have to use `for` to apply the iterator. We can also explicitly call `next`.
 fn print_digits_v1(b: &BigInt) {
     let mut iter = b.iter();

-    // `loop` is the keyword for a loop without a condition: It runs endlessly, or until you break out of
-    // it with `break` or `return`.

     loop {
         // Each time we go through the loop, we analyze the next element presented by the iterator - until it stops.
     loop {
         // Each time we go through the loop, we analyze the next element presented by the iterator - until it stops.

-        match iter.next() {
-            None => break,
-            Some(digit) => println!("{}", digit)
-        }
+        unimplemented!()

     }
 }
 
     }
 }
 

-// Now, it turns out that this combination of doing a loop and a pattern matching is fairly common, and Rust
-// provides some convenient syntactic sugar for it.

 fn print_digits_v2(b: &BigInt) {
     let mut iter = b.iter();
 fn print_digits_v2(b: &BigInt) {
     let mut iter = b.iter();

-    // `while let` performs the given pattern matching on every round of the loop, and cancels the loop if the pattern
-    // doesn't match. There's also `if let`, which works similar, but of course without the loopy part.

     while let Some(digit) = iter.next() {
         println!("{}", digit)
     }
 }
 
     while let Some(digit) = iter.next() {
         println!("{}", digit)
     }
 }
 

-// ## Iterator invalidation and lifetimes
-// You may have been surprised that we had to explicitly annotate a lifetime when we wrote `Iter`. Of
-// course, with lifetimes being present at every borrow in Rust, this is only consistent. But do we at
-// least gain something from this extra annotation burden? (Thankfully, this burden only occurs when we
-// define *types*, and not when we define functions - which is typically much more common.)
+// **Exercise 09.1**: Write a testcase for the iterator, making sure it yields the corrects numbers.

 // 
 // 

-// It turns out that the answer to this question is yes! This particular aspect of the concept of
-// lifetimes helps Rust to eliminate the issue of *iterator invalidation*. Consider the following
-// piece of code.
+// **Exercise 09.2**: Write a function `iter_ldf` that iterators over the digits with the least-significant
+// digits coming first. Write a testcase for it.
+
+// ## Iterator invalidation and lifetimes
+

 fn iter_invalidation_demo() {
     let mut b = BigInt::new(1 << 63) + BigInt::new(1 << 16) + BigInt::new(1 << 63);
     for digit in b.iter() {
 fn iter_invalidation_demo() {
     let mut b = BigInt::new(1 << 63) + BigInt::new(1 << 16) + BigInt::new(1 << 63);
     for digit in b.iter() {


@@ -102,22 +71,15 @@ fn iter_invalidation_demo() {
         /*b = b + BigInt::new(1);*/                                 /* BAD! */
     }
 }
         /*b = b + BigInt::new(1);*/                                 /* BAD! */
     }
 }

-// If you enable the bad line, Rust will reject the code. Why? The problem is that we are modifying the
-// number while iterating over it. In other languages, this can have all sorts of effects from inconsistent
-// data or throwing an exception (Java) to bad pointers being dereferenced (C++). Rust, however, is able to
-// detect this situation. When you call `iter`, you have to borrow `b` for some lifetime `'a`, and you obtain
-// `Iter<'a>`. This is an iterator that's only valid for lifetime `'a`. Gladly, we have this annotation available
-// to make such a statement. Now, since we are using the iterator throughout the loop, `'a` has to span the loop.
-// This `b` is borrowed for the duration of the loop, and we cannot mutate it. This is yet another example for
-// how the combination of mutation and aliasing leads to undesired effects (not necessarily crashes, like in Java),
-// which Rust successfully prevents.
-// 
-// Technically speaking, there's one more subtlety that I did not explain yet. We never explicitly tied the lifetime `'a` of the
-// iterator to the loop so how does this happen? The answer lies in the full type of `next()`:
-// `fn<'a, 'b>(&'b mut Iter<'a>) -> Option<u64>`. Since `next()` takes a *borrowed* iterator, there are two lifetimes involved:
-// The lifetime of the borrow of the iterator, and the lifetime of the iterator itself. In such a case of nested lifetimes,
-// Rust implicitly adds the additional constraint that the inner lifetime *outlives* the outer one: The borrow of an iterator
-// cannot be valid for longer than the iterator itself is valid. This means that the lifetime `'a` of the iterator needs
-// to outlive every call to `next()`, and hence the loop. Lucky enough, this all happens without our intervention.

 
 

+// ## Iterator conversion trait
+
+impl<'a> IntoIterator for &'a BigInt {
+    type Item = u64;
+    type IntoIter = Iter<'a>;
+    fn into_iter(self) -> Iter<'a> {
+        self.iter()
+    }
+}
+// With this in place, you can now replace `b.iter()` in `main` by `&b`. Go ahead and try it! <br/>