---
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 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.)
)
```
Notice how we iterate over the elements of the list and make sure that we own whatever memory is to own there.
-(I love how `all` [really exists for iterators](https://doc.rust-lang.org/beta/std/iter/trait.Iterator.html#method.all) so I can express quantification over lists without any hassle. ;)
+(I love how `all` [really exists for iterators](https://doc.rust-lang.org/beta/std/iter/trait.Iterator.html#method.all) so I can express quantification over lists without any hassle. :)
This invariant already justifies `print_all`: All the entries we are going to see there are in the list, so we have their `T.pin` at our disposal and are free to call `Debug::fmt`.
I spelled out the details [in the RFC issue](https://github.com/rust-lang/rfcs/pull/2349#issuecomment-372109981).
So, if we want to declare that shared pinning is a typestate in its own right---which overall seems desirable---do we want it to be restricted like this due to an implementation detail of arbitrary self types?
+**Update:** @Diggsey [points out](https://github.com/rust-lang/rfcs/pull/2349#issuecomment-379230538) that we can still have a `PinRefCell` with a method like `fn get_pin(self: Pin<PinRefCell<T>>) -> Pin<T>`, as long as the `PinRefCell` never gives out mutable references. So it turns out that combining interior mutability and pinning should work fine, but having both pinned and unpinned interior mutability in the same type is where things start to go wrong due to `Pin::deref`. **/Update**
+
## 4 Conclusion
Leaving aside the last part about shared pinning, I am really excited how all of this fits together so nicely.
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
projects / web.git / blobdiff