+// 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)
+ }
+ }
+}
+
+// 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.)
+//
+// 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() {
+ println!("{}", digit);
+ /*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.
+
+
projects / rust-101.git / commitdiff