link to sloonz's script

[web.git] / personal / _posts / 2023-06-02-tree-borrows.md

diff --git a/personal/_posts/2023-06-02-tree-borrows.md b/personal/_posts/2023-06-02-tree-borrows.md
index 46aab46fc04691bc061c4058d159a2cdbe1f0ac0..8c82a20bf28cd215c999b63878188ccf5b4cf6de 100644 (file)
--- a/personal/_posts/2023-06-02-tree-borrows.md
+++ b/personal/_posts/2023-06-02-tree-borrows.md
@@ -155,7 +155,7 @@ More controversially, TB also changes how precisely things become read-only when
 In particular, for `&(i32, Cell<i32>)`, TB allows mutating *both* fields, including the first field which is a regular `i32`, since it just treats the entire reference as "this allows aliasing".[^1]
 In contrast, SB actually figured out that the first 4 bytes are read-only and only the last 4 bytes allow mutation via aliased pointers.
 
-[^1]: This does not mean that we bless such mutation! It just means that the compiler cannot use immutability of the first field for its optimizations. Basically, immutability of that field becomes a [safety invariant instead of a validity invariant]({% post_url 2018-08-22-two-kinds-of-invariants %}): when you call foreign code, you can still rely on it not mutating that field, but within the privacy of your own code you are allowed to mutate it.
+[^1]: This does not mean that we bless such mutation! It just means that the compiler cannot use immutability of the first field for its optimizations. Basically, immutability of that field becomes a [safety invariant instead of a validity invariant]({% post_url 2018-08-22-two-kinds-of-invariants %}): when you call foreign code, you can still rely on it not mutating that field, but within the privacy of your own code you are allowed to mutate it. See [my response here](https://www.reddit.com/r/rust/comments/13y8a9b/comment/jmlvgun/) for some more background.
 
 The reason for this design decision is that the general philosophy with TB was to err on the side of allowing more code, having less UB (which is the opposite direction than what I used with SB).
 This is a deliberate choice to uncover as much of the design space as we can with these two models.
@@ -222,3 +222,4 @@ If you run into any surprises or concerns, please let us know!
 The [t-opsem Zulip](https://rust-lang.zulipchat.com/#narrow/stream/136281-t-opsem) and the [UCG issue tracker](https://github.com/rust-lang/unsafe-code-guidelines/) are good places for such questions.
 
 That's all I got, thanks for reading -- and a shout out to Neven for doing all the actual work here (and for giving feedback on this blog post), supervising this project has been a lot of fun!
+Remember to read [his write up](https://perso.crans.org/vanille/treebor/) and [watch his talk](https://www.youtube.com/watch?v=zQ76zLXesxA).