tweaks

diff --git a/personal/_posts/2017-07-17-types-as-contracts.md b/personal/_posts/2017-07-17-types-as-contracts.md
index 12276415b34b2d43dc20217d52d36de7717a1deb..6bcaea00e2aaa8a212ff32801d0d4cc4a592dbde 100644 (file)
--- a/personal/_posts/2017-07-17-types-as-contracts.md
+++ b/personal/_posts/2017-07-17-types-as-contracts.md
@@ -321,8 +321,7 @@ If a function takes an `x: &Cell<i32>`, following the rules above, it will acqui
 Clearly, we do not want to do that -- calling `x.set` *will* actually mutate `*x`, and mutating through a shared reference is exactly the point of using `Cell`!
 
 Lucky enough, the compiler *already* says that interior mutability is only allowed via [`UnsafeCell`](https://doc.rust-lang.org/beta/core/cell/struct.UnsafeCell.html).
 Clearly, we do not want to do that -- calling `x.set` *will* actually mutate `*x`, and mutating through a shared reference is exactly the point of using `Cell`!
 
 Lucky enough, the compiler *already* says that interior mutability is only allowed via [`UnsafeCell`](https://doc.rust-lang.org/beta/core/cell/struct.UnsafeCell.html).

-We can use this for our purposes: To adjust validation for interior mutability, we *stop* our recursive descent and do not do anything when reaching an `UnsafeCell` *while `mutbl` indicates we are in immutable mode*.
-(`&mut UnsafeCell` is not affected.)
+We can use this for our purposes: To adjust validation for interior mutability, we *stop* our recursive descent and do not do anything when reaching an `UnsafeCell` *while `mutbl` indicates we are in immutable mode* -- `&mut UnsafeCell` is not affected.

 In particular, no locks are acquired.
 This justifies calling `set` on a shared reference and having the value changed.
 Of course, it also means we cannot do some of the optimizations we discussed above -- but that's actually exactly what we want!
 In particular, no locks are acquired.
 This justifies calling `set` on a shared reference and having the value changed.
 Of course, it also means we cannot do some of the optimizations we discussed above -- but that's actually exactly what we want!