New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tracking issue for async / await #804

carllerche opened this Issue Dec 19, 2018 · 0 comments


None yet
1 participant
Copy link

carllerche commented Dec 19, 2018

This is a tracking issue representing the work to migrate Tokio to fully use async/await. Actual work will happen over time as progress is unblocked by ecosystem progress.


Tokio will rapidly include support for async/await as it becomes available. The path to fully removing futures 0.1 will take longer.

  • Provide experimental opt-in async/await support.
  • Provide stable async/await support.
  • Switch to async/await as the primary API.
  • Remove futures 0.1 support.

Experimental async/await support.

This is provided today by depending on tokio with the async-await-preview feature flag. More details can be found here.

The current implementation of the async/await support is limited in that it only works with 0.1 futures. This is fixable. Until then, the futures 0.3 compat() API can be used.

Provide stable async/await support.

Once async/await becomes available on the stable Rust channel, Tokio will stabilize the async-await-preview flag (by dropping -preview).

This step provides full capabilities for Tokio and async/await, but with a slightly less ergonomic API (functions will have an _async suffix).

This step will also happen very soon after async/await is on the stable channel.

Switch to async/await as primary API.

The initial async/await integration will provide the ability to figure out and incubate Tokio's async/await API. Once async/await and Tokio's integration is deemed mature enough, a breaking release will be issued switching Tokio to use async/await as the primary API. This will mostly mean dropping the _async suffixes and other mechanical changes.

Given that the ecosystem will not update all at once (it will take a long time!) Tokio will still support futures 0.1 based libraries via a compatibility layer.

The specific time frame for this step is unknown as it depends on the required ecosystem components being deemed mature enough to depend on in production contexts.

Remove futures 0.1 support.

Finally, futures 0.1 support is full removed. At this point, it is just a question of deleting the compatibility layer.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment