Are you using this crate?

[withoutboats]

This crate has been in maintenance mode (and pitifully maintained) for several months. However, at this point, I think it might be time to straight deprecate it. There are now bridges between the futures 0.3 version (which is used by the async/await native syntax) and the futures 0.1 version (which is used by libraries like tokio and hyper) provided in the tokio-async-await crate.

So I'm asking: are you still using this crate? If so, what is stopping you from moving to native syntax?

[joepie91]

I opted for not using this package due to the limitations stated in the README, and stuck with combinator syntax instead.

However, it is news to me that there is an alternative option at all. Despite quite a lot of searching, I've not been able to find anything about "native async/await syntax" or how to use it with futures, anywhere - just mentions of it being worked on. Could you elaborate on this?

[withoutboats]

Async/await is implemented on nightly, for example:

#![feature(async_await, futures_api, await_macro)]

use std::future::Future;

async fn foo<F: Future<Output = i32> + 'static>(x: &i32, future: F) -> i32 {
    let y = await!(future);
    *x + y
}

[joepie91]

Thanks! Is there any formal documentation about this feature anywhere?

I'm particularly interested in the limitations of it (if any), and I suspect that many of the users of this crate also wouldn't be aware of this, and might continue using this crate for that reason. Even searching specifically for those feature names, I can't find anything that looks comprehensive or authorative.

[withoutboats]

Thanks! Is there any formal documentation about this feature anywhere?

There's an RFC but that's about it so far. rust-lang/rfcs#2394

[mikong]

I was looking for information about async/await after watching a talk about Tokio, and this repo is the first relevant result in my search. It wasn't immediately clear if this is being deprecated (until I checked the issues). I think it would be great if information about where to check instead is shown at the very top of the README (link to the RFC), and maybe a link to this issue for people who are using this crate.

[alex]

I'm still using this crate. I suspect I can move to native async/await, however I'm running into exciting mismatches between await!() which wants a std::future::Future, and futures from hyper which are future::Future. Is there any documentation on what you need to do to bridge this?

[withoutboats]

Is there any documentation on what you need to do to bridge this?

There's some compatibility shims in the futures crate, and an even more convenient shim in tokio-async-await, which replaces the await! macro from std with one that can await both futures 0.3 and futures 0.1.

[alex]

Do you have a link to the docs on the future crate shims? I'm not seeing it in the docs for futures or std::futures.

…

On Mon, Nov 12, 2018 at 8:36 AM boats ***@***.***> wrote: Is there any documentation on what you need to do to bridge this? There's some compatibility shims in the futures crate, and an even more convenient shim in tokio-async-await, which replaces the await! macro from std with one that can await both futures 0.3 and futures 0.1. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#111 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAADBBwihRnfq6xd-v4wGqYLVKZds_LYks5uuXl3gaJpZM4X34BS> .

-- All that is necessary for evil to succeed is for good people to do nothing.

[withoutboats]

Are you looking at the right futures crate? You want the futures-preview crate (the main futures is just the old 0.1 version until we release futures 0.3 properly). It has a compat module. The other crate I mentioned with the await macro is here.

[Nemo157]

@alex there's also an unreleased blog post about the compat shims. The blog post is based on a slightly older version where the TryFutureExt::compat method took a spawner, that's now removed since std::futures doesn't natively support spawning, but the rest is still relevant

[alex]

Ahhh! No, I wasn't looking at the right futures crate, thanks.

…

On Mon, Nov 12, 2018 at 8:45 AM boats ***@***.***> wrote: Are you looking at the right futures crate? You want the futures-preview <https://crates.io/crates/futures-preview> crate (the main futures is just the old 0.1 version until we release futures 0.3 properly). It has a compat <https://rust-lang-nursery.github.io/futures-api-docs/0.3.0-alpha.9/futures/compat/index.html> module. The other crate I mentioned with the await macro is here <https://crates.io/crates/tokio-async-await>. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#111 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAADBCemugMCHeKpS7v3tdgDJ_9fkvhuks5uuXuGgaJpZM4X34BS> .

-- All that is necessary for evil to succeed is for good people to do nothing.

[vorot93]

Is there an #[async_stream] replacement out there?

[ajsyp]

I agree with @vorot93: I depend on this crate quite a bit because, as far as I can tell, there is no other way forward that replaces #[async_stream], which I use extensively. Would love to switch over to the new built-in async/await syntax and futures 0.3, though. @withoutboats -- do you know of a way to write native async streams? Or a compatibility shim for "async generators" (which yield stream elements and which could await! on other futures)?

[jimmycuadra]

I'm also unclear how we're supposed to approach async for loops with futures-preview, as my understanding was that is not part of what's being moved into std.

Edit:

As far as I can tell, the way to do this is what's shown in this blog post about Tokio's async/await support: https://tokio.rs/blog/2018-08-async-await/

tl;dr: Await a single future from a stream using a while loop.

[withoutboats]

Yes the way to write a for loop is to await the next future in a while loop. There's no replacement for asnyc_stream on futures 0.3 right now.

[ajsyp]

In that case, can we leave the crate un-deprecated until a replacement is available?

[jethrogb]

So I'm asking: are you still using this crate?

Yes.

If so, what is stopping you from moving to native syntax?

Nothing, it was just really hard to find out what the "correct" way to do things is when I started a new project about a month ago. This crate popped up as a reasonably working option. Maybe do a new crates.io release and recommend migration in the readme?

[vorot93]

@withoutboats @ajsyp
I have created an async_stream alternative based on futures 0.3 and generators. Hopefully it may put this package to rest.

https://github.com/vorot93/gen-stream

[ajsyp]

@vorot93 Great! I saw your post on reddit earlier, will definitely give this a shot.

[taiki-e]

I have a patch to support #[async] for and #[async_stream] in futures 0.3: rust-lang/futures-rs@master...taiki-e:async-stream

Currently, this is blocked in work for the futures_api stabilization (rust-lang/futures-rs#1514), but after the futures 0.3.0-alpha.14 is released, I will open a PR for this.

However, this patch is too big and will take a long time to review, so I may prefer to add only #[async] for to futures-rs (rust-lang/futures-rs@master...taiki-e:for-await) and support #[async_stream] in the other repository.

In any case, we can use these features in the not‐too‐distant future.