add forum link

[web.git] / ralf / _posts / 2018-04-05-a-formal-look-at-pinning.md

diff --git a/ralf/_posts/2018-04-05-a-formal-look-at-pinning.md b/ralf/_posts/2018-04-05-a-formal-look-at-pinning.md
index 1f095233d11dae45eee195f2396507d32aa8f207..a82c9cdad329543e0cf0f98a87bf1a1600e9ad1a 100644 (file)
--- a/ralf/_posts/2018-04-05-a-formal-look-at-pinning.md
+++ b/ralf/_posts/2018-04-05-a-formal-look-at-pinning.md
@@ -1,6 +1,7 @@
 ---
 title: "A Formal Look at Pinning"
 categories: research rust
+forum: https://internals.rust-lang.org/t/a-formal-look-at-pinning/7236
 ---
 
 Recently, a new API for "pinned references" has [landed as a new unstable feature](https://github.com/rust-lang/rust/pull/49058) in the standard library.
@@ -321,5 +322,5 @@ I hope I was able to shed some light both on how pinning is useful, and how we c
 Next time, we are going to look at an extension to the pinning API proposed by @cramertj which guarantees that `drop` will be called under some circumstances, and how that is useful for intrusive collections.
 
 Thanks for reading!
-I am looking forward to hearing your comments.
+I am looking forward to hearing your [comments](https://internals.rust-lang.org/t/sharing-for-a-lifetime/7236).
 In particular, I am curious if the made-up syntax for making the typestate invariants more precise was helpful.