Update futures2 to use the futures 0.2 release

[srijs]

No description provided.

[dimbleby]

Seeing as how futures v0.2.0-beta doesn't seem to compile (below) there is, so far as I can see, currently no way to use tokio with features = ["unstable-futures"].

That's gonna make it hard for people to experiment with the newly available futures 0.2 release.

So: it would be extremely helpful if you could take this pull request and publish, please!

   Compiling futures v0.2.0-beta
error[E0603]: module `close` is private
   --> /data/dch/.cargo/registry/src/github.com-1ecc6299db9ec823/futures-0.2.0-beta/src/lib.rs:298:31
    |
298 |         WithFlatMap, SinkExt, close, flush,
    |                               ^^^^^

error[E0603]: module `flush` is private
   --> /data/dch/.cargo/registry/src/github.com-1ecc6299db9ec823/futures-0.2.0-beta/src/lib.rs:298:38
    |
298 |         WithFlatMap, SinkExt, close, flush,
    |                                      ^^^^^

error: aborting due to 2 previous errors

error: Could not compile `futures`.

[carllerche]

Based on this thread, it doesn't seem like futures 0.2 is being considered stable. Also, there are still a number of issues (#251), including a severe memory safety bug (#254).

Given all this, and no timeline for making the futures2 feature flag stable, I wonder if a better route would be a futures compatibility layer. @seanmonstar is exploring this here.

Thoughts?

[carllerche]

Anyway, since this fixes the build, I will merge this PR. We will wait for @aturon to be back from PTO before making any decisions.

Thanks for the PR @srijs.

[dimbleby]

Ack that futures 0.2 may not be stable. But even so: as I understand it the point of that release was to ask people to experiment with it. Seeing as how tokio is likely the principal method for most people actually to execute their futures... it would be very helpful for there to be a tokio release that was compatible.

(I've no objection to that being behind an unstable feature flag).

[carllerche]

What do you think about compatibility being provided via a compat lib? As of now, there are severe issues with the futures 0.2 integration and no resources allocated to fixing them.

…

On Mon, Apr 9, 2018 at 12:55 AM David Hotham ***@***.***> wrote: Ack that futures 0.2 may not be stable. But even so: as I understand it the point of that release was to ask people to experiment with it. Seeing as how tokio is likely the principle method for most people actually to execute their futures... it would be very helpful for there to be a tokio release that was compatible. (I've no objection to that being behind an unstable feature flag). — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#304 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAYJI50oWawoZX320mDeY9bTRL11Eakks5tmxPogaJpZM4TK4GT> .

[seanmonstar]

@dimbleby I'd recommend not enabling the unstable feature, as it has a use-after-free bug in it.

[dimbleby]

I'm not especially bothered about the mechanism for using this with futures 0.2 - or even that it has bugs.

Simply, I have gone: futures 0.2 is released, they'd like me to play with it, OK I'll do that, well shucks tokio isn't compatible.

Since my plan had been: let's see what happens if I port my futures 0.1 code to futures 0.2, and since that code uses tokio - game over.

Re resource shortage: maybe it's worth reaching out to people working on futures? Seems like it should be in their interest to have a tokio that's compatible with futures 0.2.

[carllerche]

@dimbleby the futures team is aware of the resource shortage.