Futures 0.2.1 crate usage example


#1

With futures 0.1.21

#![feature(proc_macro, generators)]
use futures::prelude::*;
#[async]
fn request_async(...) { ... }

but with futures 0.2.1

error: cannot find attribute macro `async` in this scope
  --> src\gnp.rs:18:3
   |
18 | #[async]

| ^^^^^

What is the missing extern-crate or use line to enable this? I’d like to use the newer interfaces if at all possible.


#2

If I recall correctly, futures 0.2.x has updated async syntax. if you want the attribute-based syntax, you can try futures 0.1.


#3

Any simple examples? The example in the github page is still 0.1.*


#4

The async syntax can be found here, and the library component has an RFC here.


#5

You’re probably missing the nightly feature flag on your futures dependency, the async stuff isn’t included by default because it requires a nightly compiler. You’ll need a dependency like futures = { version = "0.2.1", features = ["nightly"] }


#6

@Nemo157 That was the key. Odd that placing #![feature(nightly)] in lib.rs didn’t cause the same effect nor did cargo +nightly build. I would have thought they are interchangeable.


#7

So, there are two different things called “feature” in Rust, along with futures reusing the name of a release channel for a crate feature. I’ll try and explain the three different things you have attempted here.

First, cargo +nightly build; this tells rustup to use the toolchain installed from the nightly release channel instead of your default one. On its own this only changes which compiler is used, unless a library does version detection in a build script (or the nightly compiler has a bug) it shouldn’t affect the behaviour of code that currently compiles on stable.

Next, #![feature(nightly)]; this is activating an “unstable feature flag” of the Rust compiler called nightly. You can see the currently supported feature flags in The Unstable Book, since this is an unknown unstable feature it doesn’t affect your code at all (I’m slightly surprised to find that activating an unknown feature flag doesn’t generate a warning).

Finally, futures = { features = ["nightly"] }; this is telling futures to activates its feature called nightly. This allows futures to conditionally include code that currently does not compile on stable Rust, you can find a description of these features in The Cargo Book.

So, one question you might have is, why doesn’t futures just detect its being compiled with a nightly compiler and activate the additional features? The problem with this is that users might be using nightly for some other reason and not want any of those additional features (e.g. cargo bench is still stuck on nightly only). The unstable features of Rust that futures requires to provide these features can break at any time (just the other day the pin feature had some renames that broke futures 0.2.1). futures also reserves the right to have breaking API changes to APIs guarded by its nightly feature, so as the Rust features used to implement these evolve so can the futures API until they are stabilized. By sticking these features behind a feature flag in futures you have to opt-in to say you’re aware that both updating your nightly compiler may break your compile until futures is updated, and that you may have compile errors even after a semver compatible update.