From 26672a60fa42784e30676f56b81c73e706ff7e85 Mon Sep 17 00:00:00 2001 From: Ralf Jung Date: Wed, 11 Apr 2018 10:55:09 +0200 Subject: [PATCH 1/1] update the update --- .../2018-04-10-safe-intrusive-collections-with-pinning.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ralf/_posts/2018-04-10-safe-intrusive-collections-with-pinning.md b/ralf/_posts/2018-04-10-safe-intrusive-collections-with-pinning.md index 923480e..5f16f20 100644 --- a/ralf/_posts/2018-04-10-safe-intrusive-collections-with-pinning.md +++ b/ralf/_posts/2018-04-10-safe-intrusive-collections-with-pinning.md @@ -453,7 +453,7 @@ Removing `Pin::deref` (or restricting it to types that implement `Unpin`) would 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>) -> Pin`, 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** +**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>) -> Pin`, as long as the `PinRefCell` never gives out mutable references. So it turns out that combining interior mutability and pinning should work fine. Later, @glaebhoerl suggested we can even [combine `RefCell` and `PinRefCell` into one type if we dynamically track the pinning state](https://internals.rust-lang.org/t/safe-intrusive-collections-with-pinning/7281/11?u=ralfjung). **/Update** ## 4 Conclusion -- 2.30.2