From: Ralf Jung Date: Wed, 8 Jul 2015 12:30:22 +0000 (+0200) Subject: complete part 09 X-Git-Url: https://git.ralfj.de/rust-101.git/commitdiff_plain/b60c82e9d3b03aa36484c1ff68f34f4e78862d46?ds=sidebyside complete part 09 --- diff --git a/src/main.rs b/src/main.rs index 27ad38e..ba75223 100644 --- 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 09: Iterators](part08.html) // * (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 d8d71b1..ef8ab92 100644 --- 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 { let mut vec: Vec = Vec::::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 - //@ 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() { @@ -40,17 +40,17 @@ fn read_vec() -> Vec { //@ 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. - //@ 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`. - //@ 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 @@ -61,7 +61,7 @@ fn read_vec() -> Vec { //@ 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) => { diff --git a/src/part05.rs b/src/part05.rs index b3b428e..b593360 100644 --- 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 { - pub data: Vec, + pub data: Vec, // least significant digit first, no trailing zeros } // 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 { - BigInt { data: vec![] } + BigInt { data: vec![] } /*@*/ } else { BigInt { data: vec![x] } /*@*/ } @@ -53,7 +53,7 @@ impl BigInt { // // **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) -> Self { unimplemented!() } diff --git a/src/part06.rs b/src/part06.rs index b39a441..5b90142 100644 --- a/src/part06.rs +++ b/src/part06.rs @@ -26,7 +26,7 @@ impl BigInt { } // 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) -> Option { let mut min: Option = None; for e in v { @@ -48,7 +48,7 @@ fn vec_min(v: &Vec) -> Option { //@ `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`.
//@ 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 Copy for SomethingOrNothing {} //@ `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. diff --git a/src/part08.rs b/src/part08.rs index 630da42..4ef9d74 100644 --- 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`. -//@ [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 63bab76..c6c32a4 100644 --- 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; -// 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`, 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`, 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.
-// `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.
+//@ `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 } @@ -34,10 +34,10 @@ impl<'a> Iterator for Iter<'a> { fn next(&mut self) -> Option { // 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 { - // Decrement, and return next digit. + // Otherwise: Decrement, and return next digit. 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 { - // 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() } /*@*/ } @@ -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(); - // `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. - 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(); - // `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) } } -// ## 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() { @@ -103,23 +108,41 @@ fn iter_invalidation_demo() { /*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`. 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!
+//@ 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) diff --git a/workspace/src/main.rs b/workspace/src/main.rs index 09954a0..4d6d230 100644 --- a/workspace/src/main.rs +++ b/workspace/src/main.rs @@ -10,6 +10,7 @@ mod part05; mod part06; mod part07; mod part08; +mod part09; // This decides which part is actually run. fn main() { diff --git a/workspace/src/part03.rs b/workspace/src/part03.rs index 5a5327c..152b525 100644 --- a/workspace/src/part03.rs +++ b/workspace/src/part03.rs @@ -10,7 +10,7 @@ use std::io; fn read_vec() -> Vec { let mut vec: Vec = Vec::::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() { diff --git a/workspace/src/part05.rs b/workspace/src/part05.rs index f1c5587..78113b7 100644 --- a/workspace/src/part05.rs +++ b/workspace/src/part05.rs @@ -4,14 +4,14 @@ // ## Big Numbers pub struct BigInt { - pub data: Vec, + pub data: Vec, // 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 { - BigInt { data: vec![] } + unimplemented!() } else { unimplemented!() } @@ -31,7 +31,7 @@ impl BigInt { // // **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) -> Self { unimplemented!() } diff --git a/workspace/src/part09.rs b/workspace/src/part09.rs index 6b3f737..61cc70b 100644 --- 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; -// 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`, 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.
-// `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 } @@ -34,10 +17,10 @@ impl<'a> Iterator for Iter<'a> { fn next(&mut self) -> Option { // 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 { - // Decrement, and return next digit. + // Otherwise: Decrement, and return next digit. 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 { - // 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!() } @@ -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(); - // `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. - 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(); - // `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) } } -// ## 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() { @@ -102,22 +71,15 @@ fn iter_invalidation_demo() { /*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`. 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!