use official plaintext version of CC license

[rust-101.git] / src / part09.rs

diff --git a/src/part09.rs b/src/part09.rs
index 2a46d771fea9f34c3be9f21cce4233efeb991655..0ca4a430178ce71be13f792733394af38acbb67b 100644 (file)
--- a/src/part09.rs
+++ b/src/part09.rs
@@ -5,7 +5,7 @@ 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 certain traits again. In particular,
 
 //@ 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),
+//@ an iterator is something that implements the `Iterator` trait. As you can see in [the documentation](https://doc.rust-lang.org/stable/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.)
 //@ 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.)


@@ -14,9 +14,9 @@ use part05::BigInt;
 //@ 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.
 //@ 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.
+//@ The only alternative is for the iterator to *borrow* the number, so it takes a reference.

 
 

-//@ In writing this down, we again have to be explicit about the lifetime of the borrow: We can't just have an
+//@ In writing this down, we again have to be explicit about the lifetime of the reference: 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",
 //@ `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",


@@ -47,7 +47,7 @@ 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
 // 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
+    //@ the case with functions returning references, 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() }                    /*@*/
     //@ same. (See the last section of [part 06](part06.html).)
     fn iter(&self) -> Iter {
         Iter { num: self, idx: self.data.len() }                    /*@*/


@@ -89,12 +89,12 @@ fn print_digits_v2(b: &BigInt) {
 
 // **Exercise 09.1**: Write a testcase for the iterator, making sure it yields the corrects numbers.
 // 
 
 // **Exercise 09.1**: Write a testcase for the iterator, making sure it yields the corrects numbers.
 // 

-// **Exercise 09.2**: Write a function `iter_ldf` that iterators over the digits with the least-significant
+// **Exercise 09.2**: Write a function `iter_ldf` that iterates 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
 // 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
+//@ course, with lifetimes being present at every reference 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.)
 
 //@ 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.)
 


@@ -121,7 +121,7 @@ fn iter_invalidation_demo() {
 // ## Iterator conversion trait
 //@ If you closely compare the `for` loop in `main` above, with the one in `part06::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`.
 // ## Iterator conversion trait
 //@ If you closely compare the `for` loop in `main` above, with the one in `part06::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, it demands an implementation of [`IntoIterator`](http://doc.rust-lang.org/beta/std/iter/trait.IntoIterator.html).
+//@ Instead, it demands an implementation of [`IntoIterator`](https://doc.rust-lang.org/stable/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
 //@ 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


@@ -130,7 +130,7 @@ fn iter_invalidation_demo() {
 //@ 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
 //@ 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 implement the trait for *borrowed* numbers, such that the number is not lost after the iteration.
+//@ consumes its argument. So we implement the trait for *references to* numbers, such that the number is not lost after the iteration.

 impl<'a> IntoIterator for &'a BigInt {
     type Item = u64;
     type IntoIter = Iter<'a>;
 impl<'a> IntoIterator for &'a BigInt {
     type Item = u64;
     type IntoIter = Iter<'a>;


@@ -140,10 +140,10 @@ impl<'a> IntoIterator for &'a BigInt {
 }
 // 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`. If we are in a place where `b` is already borrowed, we can
 }
 // 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`. If we are in a place where `b` is already borrowed, we can

-//@ just do `for digit in b`. If however, we own `b`, we have to borrow it. Alternatively, we could implement `IntoIterator`
+//@ just do `for digit in b`. If however, we own `b`, we have to create a reference to it. Alternatively, we could 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` (and `&mut 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
 //@ `part01::vec_min`, but we did not care. You can write `for e in &v` or `for e in v.iter()` to avoid this.
 
 //@ 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` (and `&mut 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
 //@ `part01::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) | [raw source](workspace/src/part09.rs) | [next](part10.html)