futures 0.2 doesnt seem to be as stable as I thought
authorRalf Jung <post@ralfj.de>
Wed, 11 Apr 2018 17:15:05 +0000 (19:15 +0200)
committerRalf Jung <post@ralfj.de>
Wed, 11 Apr 2018 17:15:05 +0000 (19:15 +0200)
ralf/_posts/2018-04-10-safe-intrusive-collections-with-pinning.md

index 5f16f20..37da65c 100644 (file)
@@ -440,6 +440,7 @@ I hope we do not end up in a situation where `insert` with a shared reference is
 That just seems like the worst of both worlds.
 
 However, now we already have a [version of the futures crate](https://aturon.github.io/2018/04/06/futures2/) using the revised `Pin`, so I don't know if changing it again is realistic. :/
+(**Update:** Seems like [there may be breaking changes in future future versions anyway](https://www.reddit.com/r/rust/comments/8ac85w/futures_02_is_here/dwxkhvl/), so maybe the ship has not yet sailed after all. **/Update**)
 I feel bad about that.  Can we still fix this before everything gets stabilized?
 Others [have](https://github.com/rust-lang/rfcs/pull/2349#issuecomment-373206171) [argued](https://github.com/rust-lang/rfcs/pull/2349#issuecomment-378555691) for a shared pinned reference after it got removed from the API, and I argued against them as I did not understand how it could be useful.
 Thanks for not being convinced by me!
@@ -463,7 +464,6 @@ I am happy to learn that I was wrong!
 I am impressed by the creativity that went into coming up with these APIs, and looking forward to analyzing more of them in the future.
 
 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](https://internals.rust-lang.org/t/safe-intrusive-collections-with-pinning/7281)!