be more explicit about the abstract machine earlier

[web.git] / personal / _posts / 2018-01-31-sharing-for-a-lifetime.md

diff --git a/personal/_posts/2018-01-31-sharing-for-a-lifetime.md b/personal/_posts/2018-01-31-sharing-for-a-lifetime.md
index 3a8af093f353182f273d4d1360410b300fe6c729..e3bcce54c632194b84fef35b087a89904c09d723 100644 (file)
--- a/personal/_posts/2018-01-31-sharing-for-a-lifetime.md
+++ b/personal/_posts/2018-01-31-sharing-for-a-lifetime.md
@@ -51,7 +51,7 @@ Overall, we conclude that we did not violate any of the invariants imposed on `x
 ## Interior Mutability
 
 Interior mutability however breaks this model of `&'a T`:  We just cannot declare that the pointed-to memory is read-only in general.
-If we did, [`Cell::set`](https://doc.rust-lang.org/beta/std/cell/struct.Cell.html#method.set) and many more operations would be blatantly unsafe.
+If we did, [`Cell::set`](https://doc.rust-lang.org/stable/std/cell/struct.Cell.html#method.set) and many more operations would be blatantly unsafe.
 Indeed this is the reason shared references are not called "immutable references" even though they are generally considered the dual of mutable references.
 (My personal thinking is that mutable references should really be called "unique references" to instill the point that the distinction between the two is about uniqueness, not about mutability.  Oh well.)
 
@@ -156,3 +156,5 @@ I honestly don't know, but I had to think of this a while back when I read [this
 
 If you have any comments or thoughts on this, please join the [discussion in the Rust forums](https://internals.rust-lang.org/t/sharing-for-a-lifetime/6675)!
 I'd also be interested in feedback on how understandable this post is; this is my first attempt at translating research results into a blog post.
+
+#### Footnotes