only &UnsafeCell is special

diff --git a/personal/_posts/2017-07-17-types-as-contracts.md b/personal/_posts/2017-07-17-types-as-contracts.md
index 2d5e3c484218d462ea9df592e453d844018bf269..e01e7509c059e3abc1267c36183148f08ad033f6 100644 (file)
--- a/personal/_posts/2017-07-17-types-as-contracts.md
+++ b/personal/_posts/2017-07-17-types-as-contracts.md
@@ -306,7 +306,8 @@ 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`.
+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!