63bab76a177aec6c49963477eecfcf06847c2d8a
[rust-101.git] / src / part09.rs
1 // Rust-101, Part 09: Iterators (WIP)
2 // ==================================
3
4 use part05::BigInt;
5
6 // In the following, we will look into the iterator mechanism of Rust and make our `BigInt` compatible
7 // with the `for` loops. Of course, this is all about implementing particular traits again. In particular,
8 // 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),
9 // this trait mandates a single function `next` returning an `Option<Self::Item>`, where `Item` is an
10 // associated type chosen by the implementation. (There are many more methods provided for `Iterator`,
11 // but they all have default implementations, so we don't have to worry about them right now).
12 // 
13 // For the case of `BigInt`, we want our iterator to iterate over the digits in normal, notational order: The most-significant
14 // digit comes first. So, we have to write down some type, and implement `Iterator` for it such that `next` returns the digits
15 // one-by-one. Clearly, the iterator must somehow be able to access the number it iterates over, and it must store its current
16 // location. However, it cannot *own* the `BigInt`, because then the number would be gone after iteration! That'd certainly be bad.
17 // The only alternative is for the iterator to *borrow* the number.
18
19 // In writing this down, we again have to be explicit about the lifetime of the borrow: We can't just have an
20 // `Iter`, we must have an `Iter<'a>` that borrowed the number for lifetime `'a`. This is our first example of
21 // a datatype that's polymorphic in a lifetime, as opposed to a type. <br/>
22 // `usize` here is the type of unsigned, pointer-sized numbers. It is typically the type of "lengths of things",
23 // 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.
24 struct Iter<'a> {
25     num: &'a BigInt,
26     idx: usize, // the index of the last number that was returned
27 }
28
29 // Now we are equipped to implement `Iterator` for `Iter`.
30 impl<'a> Iterator for Iter<'a> {
31     // We choose the type of things that we iterate over to be the type of digits, i.e., `u64`.
32     type Item = u64;
33
34     fn next(&mut self) -> Option<u64> {
35         // First, check whether there's any more digits to return.
36         if self.idx == 0 {
37             // We already returned all the digits.
38             None                                                    /*@*/
39         } else {
40             // Decrement, and return next digit.
41             self.idx = self.idx - 1;                                /*@*/
42             Some(self.num.data[self.idx])                           /*@*/
43         }
44     }
45 }
46
47 // All we need now is a function that creates such an iterator for a given `BigInt`.
48 impl BigInt {
49     // 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
50     // the case with functions returning borrowed data, you can elide the lifetime. The rules for adding the lifetimes are exactly the
51     // same. (See the last section of [part 06](part06.html).)
52     fn iter(&self) -> Iter {
53         Iter { num: self, idx: self.data.len() }                    /*@*/
54     }
55 }
56
57 // We are finally ready to iterate! Remember to edit `main.rs` to run this function.
58 pub fn main() {
59     let b = BigInt::new(1 << 63) + BigInt::new(1 << 16) + BigInt::new(1 << 63);
60     for digit in b.iter() {
61         println!("{}", digit);
62     }
63 }
64
65 // Of course, we don't have to use `for` to apply the iterator. We can also explicitly call `next`.
66 fn print_digits_v1(b: &BigInt) {
67     let mut iter = b.iter();
68     // `loop` is the keyword for a loop without a condition: It runs endlessly, or until you break out of
69     // it with `break` or `return`.
70     loop {
71         // Each time we go through the loop, we analyze the next element presented by the iterator - until it stops.
72         match iter.next() {
73             None => break,
74             Some(digit) => println!("{}", digit)
75         }
76     }
77 }
78
79 // Now, it turns out that this combination of doing a loop and a pattern matching is fairly common, and Rust
80 // provides some convenient syntactic sugar for it.
81 fn print_digits_v2(b: &BigInt) {
82     let mut iter = b.iter();
83     // `while let` performs the given pattern matching on every round of the loop, and cancels the loop if the pattern
84     // doesn't match. There's also `if let`, which works similar, but of course without the loopy part.
85     while let Some(digit) = iter.next() {
86         println!("{}", digit)
87     }
88 }
89
90 // ## Iterator invalidation and lifetimes
91 // You may have been surprised that we had to explicitly annotate a lifetime when we wrote `Iter`. Of
92 // course, with lifetimes being present at every borrow in Rust, this is only consistent. But do we at
93 // least gain something from this extra annotation burden? (Thankfully, this burden only occurs when we
94 // define *types*, and not when we define functions - which is typically much more common.)
95 // 
96 // It turns out that the answer to this question is yes! This particular aspect of the concept of
97 // lifetimes helps Rust to eliminate the issue of *iterator invalidation*. Consider the following
98 // piece of code.
99 fn iter_invalidation_demo() {
100     let mut b = BigInt::new(1 << 63) + BigInt::new(1 << 16) + BigInt::new(1 << 63);
101     for digit in b.iter() {
102         println!("{}", digit);
103         /*b = b + BigInt::new(1);*/                                 /* BAD! */
104     }
105 }
106 // If you enable the bad line, Rust will reject the code. Why? The problem is that we are modifying the
107 // number while iterating over it. In other languages, this can have all sorts of effects from inconsistent
108 // data or throwing an exception (Java) to bad pointers being dereferenced (C++). Rust, however, is able to
109 // detect this situation. When you call `iter`, you have to borrow `b` for some lifetime `'a`, and you obtain
110 // `Iter<'a>`. This is an iterator that's only valid for lifetime `'a`. Gladly, we have this annotation available
111 // to make such a statement. Now, since we are using the iterator throughout the loop, `'a` has to span the loop.
112 // This `b` is borrowed for the duration of the loop, and we cannot mutate it. This is yet another example for
113 // how the combination of mutation and aliasing leads to undesired effects (not necessarily crashes, like in Java),
114 // which Rust successfully prevents.
115 // 
116 // Technically speaking, there's one more subtlety that I did not explain yet. We never explicitly tied the lifetime `'a` of the
117 // iterator to the loop so how does this happen? The answer lies in the full type of `next()`:
118 // `fn<'a, 'b>(&'b mut Iter<'a>) -> Option<u64>`. Since `next()` takes a *borrowed* iterator, there are two lifetimes involved:
119 // The lifetime of the borrow of the iterator, and the lifetime of the iterator itself. In such a case of nested lifetimes,
120 // Rust implicitly adds the additional constraint that the inner lifetime *outlives* the outer one: The borrow of an iterator
121 // cannot be valid for longer than the iterator itself is valid. This means that the lifetime `'a` of the iterator needs
122 // to outlive every call to `next()`, and hence the loop. Lucky enough, this all happens without our intervention.
123
124
125 //@ [index](main.html) | [previous](part08.html) | [next](main.html)