Switch to std::future::Future

[ebkalderon]

Transitioning from futures 0.1 to std::future::Future would greatly improve the user experience in the near future, especially with async/await stabilizing in Rust 1.39 and std::future::Future compatible versions of tokio, hyper, and tower on the horizon. It seems that jsonrpc-core is currently the only library in my personal JSON-RPC projects that still relies exclusively on futures 0.1, and it is blocking me from switching over to the new trait completely. I understand if this issue will sit on the backburner for the time being until at least tokio 0.2.0 is released, though.

[tomusdrw]

Yeah, I think it would be great to switch at least jsonrpc-core (and derive maybe) initially, the transports would be fine with the Compat layer.

@tomaka you have some experience with porting to std::future, any hints? :)

[tomaka]

Most of the transition should be straight-forward, except that you might have to add where F: Unpin a bit everywhere. The tokio runtime can be replaced with what is in futures-preview::executor.

One part where it might be difficult is that libraries compatible with new futures have ditched lots of combinators in favour of async-await-friendly methods that borrow objects. For example, calling incoming() of async-std::TcpListener (which returns a stream of incoming connections) no longer takes ownership of the TcpListener but borrows it. This is very user-friendly with async/await, but is a pain in the ass if you don't have access to async/await yet. In libp2p, we decided to wait for async/await to be stable for this reason.

Also, unless that changed, if you use tokio for networking, you will have to use tokio for executing futures as well. I'd encourage using futures-timer and async-std instead of tokio.

[ebkalderon]

According to Rust Forge, version 1.39 will land on November 7th, which will include stable async/await. In that case, should we start transitioning to std::future::Future now? Or should we wait for the API redesign that @tomaka is working on to land first?

[tomusdrw]

I think it's worth start the transition, I didn't have time to look into it yet. I'd be really happy to accept a PR though if you are interested in working on this @ebkalderon :)

[ebkalderon]

@tomusdrw Sure, I suppose I can try!

[ebkalderon]

I've successfully converted jsonrpc-core to std::future::Future, but I am blocked on jsonrpc-server-utils since it requires tokio, and tokio-sync >=0.2.0-alpha.2 apparently requires a nightly compiler and async/await.

EDIT: See the switch-to-std-future branch for details.

One particularly unfortunate change in futures 0.3 is the loss of the IntoFuture trait, which means that closures passed to IoHandler::handle_request(), IoDelegate::add_method(), and all related methods look a bit less nice than they do currently. This isn't a deal-breaker, though, as the crate is still perfectly usable without it.

[tomusdrw]

Can we just convert jsonrpc-core for now and use the Compat layer for the rest?

[ebkalderon]

@tomusdrw Almost, but not quite. It seems we will also need to make some changes to jsonrpc-derive, since the code produced by MethodRegistration::generate() makes use of the now-nonexistent IntoFuture trait. We will likely need to explicitly check whether each RPC method returns Result or a future type, and wrap the former in a futures::future::ready() where necessary. I'm not exactly sure how to do this with syn, but I assume there is a way.

[ebkalderon]

Apparently, there was mention of IntoFuture in the original async/await Rust RFC, as I had learned from this recent blog post, but it seems it was permanently dropped. I'm not exactly sure how to move forward with the conversion process since the lack of IntoFuture will likely substantively break the functionality of jsonrpc-derive.

[tomusdrw]

We can force the methods to return a Future instead of IntoFuture. So sync calls won't be a first-class citizen any more.

Please also follow https://github.com/paritytech/jsonrpsee/ as that's a new library we are working on that is fully Futures-based.

[frondeus]

Now async/await is stable - do you need any help with migration @ebkalderon?

[ebkalderon]

@frondeus Stability of async/await wasn't exactly a blocker for starting migration, but rather the removal of the IntoFuture trait. I don't believe this library can be migrated to async/await without changing the API semantics since it relies very heavily on IntoFuture in order to have the API accept both Result and Future types in numerous areas, with the distinction being that the former is used for synchronous requests and the latter for asynchronous requests. I'm personally waiting for jsonrpsee to stabilize and replace this library completely, since the IoHandler architecture was apparently overdue for a redesign anyway. See the comment from @tomusdrw above.

[ebkalderon]

Good news, looks like IntoFuture is coming back! It might be possible to convert jsonrpc-core as-is to async/await if this lands. 🎉

[Thegaram]

Hey @ebkalderon, now that IntoFuture is back, do you think it would be more straightforward to migrate to std::future?

I'm trying to call an async function from within my RPC handler but I find it troublesome to convert the result to futures::Future. Would be awesome if we could just write async handlers directly.

[frondeus]

It is not back yet - it was reverted cause of some strange performance drops.
rust-lang/rust#67982