From: Ralf Jung <post@ralfj.de>
Date: Tue, 21 Jul 2015 12:49:37 +0000 (+0200)
Subject: exterior mutability -> inherited mutability, another useful link, warn about transmute
X-Git-Url: https://git.ralfj.de/rust-101.git/commitdiff_plain/1f6a5ed7a44ed00827fd3312503f20b8f52f94db?hp=a7fde6ca45fecd14ac7764f47d74a76bb8853352

exterior mutability -> inherited mutability, another useful link, warn about transmute
---

diff --git a/src/main.rs b/src/main.rs
index 02766c6..97d3530 100644
--- a/src/main.rs
+++ b/src/main.rs
@@ -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)
diff --git a/src/part12.rs b/src/part12.rs
index d5b7ce3..58afd8d 100644
--- a/src/part12.rs
+++ b/src/part12.rs
@@ -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.
diff --git a/src/part16.rs b/src/part16.rs
index c02959d..22c912a 100644
--- a/src/part16.rs
+++ b/src/part16.rs
@@ -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.