From d7f72237fdbfb0771307c1e3c4a4d2e053857b9c Mon Sep 17 00:00:00 2001 From: Ralf Jung Date: Tue, 18 Jul 2017 21:27:31 -0700 Subject: [PATCH] tweaks --- personal/_posts/2017-07-17-types-as-contracts.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/personal/_posts/2017-07-17-types-as-contracts.md b/personal/_posts/2017-07-17-types-as-contracts.md index 1227641..6bcaea0 100644 --- 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`, 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). -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! -- 2.30.2