publish Tree Borrows post

diff --git a/personal/_drafts/tree-borrows.md b/personal/_posts/2023-06-02-tree-borrows.md
similarity index 97%
rename from personal/_drafts/tree-borrows.md
rename to personal/_posts/2023-06-02-tree-borrows.md
index ede3c0f292fa07ebeefa5d4f0a06d9c060bbf112..3c4f0c7fd43fca3f2e2a8a5883a3388d50a50b15 100644 (file)
--- a/personal/_drafts/tree-borrows.md
+++ b/personal/_posts/2023-06-02-tree-borrows.md
@@ -10,6 +10,7 @@ Indeed there is, but Stacked Borrows is just one proposal for a possible aliasin
 The purpose of Tree Borrows is to take the lessons learned from Stacked Borrows to build a new model with fewer issues, and to take some different design decisions such that we get an idea of some of the trade-offs and fine-tuning we might do with these models before deciding on the official model for Rust.
 
 Neven has written a detailed introduction to Tree Borrows [on his blog](https://perso.crans.org/vanille/treebor/), which you should go read first.
 The purpose of Tree Borrows is to take the lessons learned from Stacked Borrows to build a new model with fewer issues, and to take some different design decisions such that we get an idea of some of the trade-offs and fine-tuning we might do with these models before deciding on the official model for Rust.
 
 Neven has written a detailed introduction to Tree Borrows [on his blog](https://perso.crans.org/vanille/treebor/), which you should go read first.

+He presented this talk at a recent RFMIG meeting, so you can also [watch his talk here](https://www.youtube.com/watch?v=zQ76zLXesxA).

 In this post, I will focus on the differences to Stacked Borrows.
 I assume you already know Stacked Borrows and want to understand what changes with Tree Borrows and why.
 
 In this post, I will focus on the differences to Stacked Borrows.
 I assume you already know Stacked Borrows and want to understand what changes with Tree Borrows and why.
 


@@ -181,6 +182,7 @@ This optimization is possible without having any special aliasing model, so SB n
 If it weren't for the stack-violating hack that already came up several times above, I think there would be a fairly easy way of fixing this problem in SB, but alas, that hack is load-bearing and too much existing code is UB if we remove it.
 Meanwhile, TB does not need any such hack, so we can do the Right Thing (TM): when doing a read, unrelated mutable references are not entirely disabled, they are just made read-only.
 This means that "read shared reference, then read mutable reference" is equivalent to "read mutable reference, then read shared reference" and the optimization is saved.
 If it weren't for the stack-violating hack that already came up several times above, I think there would be a fairly easy way of fixing this problem in SB, but alas, that hack is load-bearing and too much existing code is UB if we remove it.
 Meanwhile, TB does not need any such hack, so we can do the Right Thing (TM): when doing a read, unrelated mutable references are not entirely disabled, they are just made read-only.
 This means that "read shared reference, then read mutable reference" is equivalent to "read mutable reference, then read shared reference" and the optimization is saved.

+(A consequence of this is that retags can also be reordered with each other, since they also act as reads. Hence the order in which you set up various pointers cannot matter, until you do the first write access with one of them.)

 
 ## Future possibility: `Unique`
 
 
 ## Future possibility: `Unique`
 


@@ -216,4 +218,4 @@ Neven has implemented Tree Borrows in Miri, so you can play around with it and c
 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.
 
 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 shout outs to Neven for doing all the actual work here, supervising this project has been a lot of fun!
+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!