X-Git-Url: https://git.ralfj.de/rust-101.git/blobdiff_plain/4f61be32dd480f23a7fef05ee66c42ae27c980c6..9ae2b045dd1772c02f7013953dd4108a99bd2c74:/src/part06.rs diff --git a/src/part06.rs b/src/part06.rs index 00a2bde..b39a441 100644 --- a/src/part06.rs +++ b/src/part06.rs @@ -25,8 +25,8 @@ 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()`. +// 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()`. fn vec_min(v: &Vec) -> Option { let mut min: Option = None; for e in v { @@ -49,7 +49,7 @@ fn vec_min(v: &Vec) -> Option { //@ `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 -//@ the copy that was created, and hence we can store it in `min`.
+//@ 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. // ## `Copy` types @@ -78,7 +78,7 @@ impl Copy for SomethingOrNothing {} //@ ## An operational perspective //@ Instead of looking at what happens "at the surface" (i.e., visible in Rust), one can also explain -//@ ownership passing and how `Copy` and `Clone` fit in by looking at what happens on the machine.
+//@ ownership passing and how `Copy` and `Clone` fit in by looking at what happens on the machine.
//@ When Rust code is executed, passing a value (like `i32` or `Vec`) to a function will always //@ result in a shallow copy being performed: Rust just copies the bytes representing that value, and //@ considers itself done. That's just like the default copy constructor in C++. Rust, however, will