add link to forum; tweak intro

diff --git a/personal/_posts/2018-04-10-safe-intrusive-collections-with-pinning.md b/personal/_posts/2018-04-10-safe-intrusive-collections-with-pinning.md
index 9ae5bd5a5b611aafd726f1187833f13c93d111e9..362a4e3dc8e27d5d8403f005952de3f9122341fc 100644 (file)
--- a/personal/_posts/2018-04-10-safe-intrusive-collections-with-pinning.md
+++ b/personal/_posts/2018-04-10-safe-intrusive-collections-with-pinning.md
@@ -1,6 +1,7 @@
 ---
 title: "Safe Intrusive Collections with Pinning"
 categories: research rust
 ---
 title: "Safe Intrusive Collections with Pinning"
 categories: research rust

+forum: https://internals.rust-lang.org/t/safe-intrusive-collections-with-pinning/7281

 ---
 
 In my [last post]({{ site.baseurl }}{% post_url 2018-04-05-a-formal-look-at-pinning %}), I talked about the new ["pinned references"](https://github.com/rust-lang/rfcs/blob/master/text/2349-pin.md) which guarantee that the data at the memory it points to will not, ever, be moved elsewhere.
 ---
 
 In my [last post]({{ site.baseurl }}{% post_url 2018-04-05-a-formal-look-at-pinning %}), I talked about the new ["pinned references"](https://github.com/rust-lang/rfcs/blob/master/text/2349-pin.md) which guarantee that the data at the memory it points to will not, ever, be moved elsewhere.


@@ -17,8 +18,9 @@ This part assumes some familiarity with the `Pin` API, but not with the formal m
 In the second part, I am going to briefly sketch a formal perspective on intrusive collections and the extended pinning guarantees.
 This builds on the formal notation I introduced in my last post.
 
 In the second part, I am going to briefly sketch a formal perspective on intrusive collections and the extended pinning guarantees.
 This builds on the formal notation I introduced in my last post.
 

-Finally, I will discuss a variant of our "running example" intrusive collection that this model can *not* handle, and how the model could be extended.
-This extended model will actually call for a change to the `Pin` API (or rather, for a revert to an earlier version).
+Finally, I will discuss a variant of our "running example" intrusive collection that combines shared references and pinning.
+It turns out this variant is actually incompatible with the formal model from the last post, but the model can be extended to fix this.
+Hiwever, this extended model will actually call for a change to the `Pin` API (or rather, for a revert to an earlier version).

 
 (Btw, I'm sorry for this blog post being *even longer* than the previous.  I guess I am just enjoying that there is no page limit (like there is in papers) when writing blog posts, so I can just ramble as much as I like.)
 
 
 (Btw, I'm sorry for this blog post being *even longer* than the previous.  I guess I am just enjoying that there is no page limit (like there is in papers) when writing blog posts, so I can just ramble as much as I like.)
 


@@ -461,6 +463,6 @@ I am impressed by the creativity that went into coming up with these APIs, and l
 The situation around shared pinning is still open, and it seems we need to have a discussion about what model we ultimately want to adopt---which code we ultimately want to be legal---and whether we want to change the `Pin` types before stabilization.
 Unfortunately I am four days late in my race against the [first significant user of this API](https://aturon.github.io/2018/04/06/futures2/).
 
 The situation around shared pinning is still open, and it seems we need to have a discussion about what model we ultimately want to adopt---which code we ultimately want to be legal---and whether we want to change the `Pin` types before stabilization.
 Unfortunately I am four days late in my race against the [first significant user of this API](https://aturon.github.io/2018/04/06/futures2/).
 

-Anyway, as usual, please let me know what you think!
+Anyway, as usual, please [let me know what you think](https://internals.rust-lang.org/t/safe-intrusive-collections-with-pinning/7281)!

 
 #### Footnotes
 
 #### Footnotes