exterior mutability -> inherited mutability, another useful link, warn about transmute
authorRalf Jung <post@ralfj.de>
Tue, 21 Jul 2015 12:49:37 +0000 (14:49 +0200)
committerRalf Jung <post@ralfj.de>
Tue, 21 Jul 2015 12:49:37 +0000 (14:49 +0200)
src/main.rs
src/part12.rs
src/part16.rs

index 02766c612d6e212b4bde8f266f0fdbb4e13fc523..97d353067e6f1f701320a5804fc19af04f798bcf 100644 (file)
@@ -122,4 +122,5 @@ fn main() {
 // * [Rust by Example](http://rustbyexample.com/)
 // * [The Advanced Rust Programming Guide](http://cglab.ca/~abeinges/blah/turpl/_book/README.html)
 // * The [Rust Subreddit](https://www.reddit.com/r/rust/)
+// * A [collection of links](https://github.com/ctjhoa/rust-learning) to blog posts, articles, videos, etc. for learning Rust.
 // * For the IRC channel and other forums, see the "Community" section of the [Rust Documentation index](http://doc.rust-lang.org/index.html)
index d5b7ce32108cb26bafbe8514c458dcb5bc956a35..58afd8da09d183a7649ab12f7697abdc2eb7df7d 100644 (file)
@@ -64,7 +64,7 @@ pub fn main() {
 //@ `set`, which overrides the content, only needs a *shared borrow* of the cell. The phenomenon of a type that permits mutation through
 //@ shared borrows (i.e., mutation despite the possibility of aliasing) is called *interior mutability*. You can think
 //@ of `set` changing only the *contents* of the cell, not its *identity*. In contrast, the kind of mutation we saw so far was
-//@ about replacing one piece of data by something else of the same type. This is called *exterior mutability*. <br/>
+//@ about replacing one piece of data by something else of the same type. This is called *inherited mutability*. <br/>
 //@ Notice that it is impossible to *borrow* the contents of the cell, and that is actually the key to why this is safe.
 
 // So, let us put our counter in a `Cell`, and replicate the example from the previous part.
index c02959d11b26303bb990bfe0800f04ed9574a066..22c912a07f71b3aaaded13dee05f741207f60296 100644 (file)
@@ -55,7 +55,8 @@ pub struct LinkedList<T> {
 
 //@ Before we get to the actual linked-list methods, we write two short helper functions converting between mutable raw pointers,
 //@ and boxed data. Both employ `mem::transmute`, which can convert anything to anything, by just re-interpreting the bytes.
-//@ Clearly, that's an unsafe operation and must only be used with great care - or even better, not at all. <br/>
+//@ Clearly, that's an unsafe operation and must only be used with great care - or even better, not at all. Seriously.
+//@ If at all possible, you should never use `transmute`. <br/>
 //@ We are making the assumption here that a `Box` and a raw pointer have the same representation in memory. In the future,
 //@ Rust will [provide](http://doc.rust-lang.org/beta/alloc/boxed/struct.Box.html#method.from_raw) such [operations](http://doc.rust-lang.org/beta/alloc/boxed/struct.Box.html#method.into_raw) in the standard library, but the exact API is still being fleshed out.
 
@@ -80,8 +81,7 @@ impl<T> LinkedList<T> {
     // This function adds a new node to the end of the list.
     pub fn push_back(&mut self, t: T) {
         // Create the new node, and make it a raw pointer.
-        //@ Calling `box_into_raw` gives up ownership of the box, which is crucial: We don't want the
-        //@ memory that it points to to be deallocated!
+        //@ Calling `box_into_raw` gives up ownership of the box, which is crucial: We don't want the memory that it points to to be deallocated!
         let new = Box::new( Node { data: t, next: ptr::null_mut(), prev: self.last } );
         let new = box_into_raw(new);
         // Update other points to this node.