accept_async does immediate async i/o unexpectedly

[zargony]

I found out the hard way that accept_async is not only returning a future that handles the handshake, but it immediately accesses the async i/o object to start the handshake and returns a future to complete it.

This means that accept_async must be called from a task context, which I think isn't obvious and maybe should be stated more clearly.

In a pure futures 0.1 application, this most probably doesn't matter since accept_async is called when the accepted TcpStream is available, which pretty much always happens inside a task. However if you're using futures 0.3, you need to wrap a future 0.1 in a compatibility wrapper to use it with 0.3 and a current task is only provided to the future while polling it. I found out the hard way that this currently doesn't work well with tokio-tungstenite (see rust-lang/futures-rs#1463).

I'd like to propose to change the accept functions to only return a future and do the actual handshake when the future gets polled. That also seems to be the way everybody else handles it (async fns, futures-rs functions and methods, any other crate I can remember) and is probably the most expected way and would make it work smoothly with futures 0.3 compatibility wrappers as far as I can see.

[daniel-abramov]

Indeed, your suggestion makes sense, thank you.

As a quick workaround I may suggest you to use futures::lazy().

[najamelan]

I can confirm that something like: ok( stream ).and_then( accept_async ) also works, but lazy is probably a better solution here.

I gave lazy a try, but I can't figure out how to properly name the type of the FnOnce. I havn't tried boxing it. However with and_then, you can name the type as:

use
{
   tungstenite       :: handshake::server::NoCallback ,
   tokio_tungstenite :: AcceptAsync                   ,
   futures01         :: future::FutureResult          ,
};

AndThen< FutureResult<T, tungstenite::error::Error>, AcceptAsync<T, NoCallback>, fn(T) -> AcceptAsync<T, NoCallback> >