Future 0.3

[prasannavl]

I know it's probably early, with futures still not being stabilized. But can we please have some kinda of alpha atleast with futures 0.3. I'd be more than happy to live on the edge with changing api surface than having to do with the madness that is the future 0.1 when in comes error types.

Converting them back and forth especially when you want to return multiple different types of errors, leads to all kind of unreadable code having to bend backwards just to pass on an error.

[DoumanAsh]

I'm not sure what @fafhrd91 feelings on this topic.
But personally I don't think it is worth investing until async/await gets into stable which is likely to happen only on next year.

Note that there is already issue for it in actix repo.
actix/actix#69

Before futures 0.3 will come to actix-web, we'd need them in actix.
But I'd prefer to avoid depending on nightly compiler as it is easy for things to break(see rocket)

[fafhrd91]

It would be interesting to see how async/await will affect actix, but I don’t have much time at the moment

[OtaK]

I'm not sure what @fafhrd91 feelings on this topic.
But personally I don't think it is worth investing until async/await gets into stable which is likely to happen only on next year.

Note that there is already issue for it in actix repo.
actix/actix#69

Before futures 0.3 will come to actix-web, we'd need them in actix.
But I'd prefer to avoid depending on nightly compiler as it is easy for things to break(see rocket)

Isn't Rust 2018 planned for 1.30 or 1.31 which would mean by the end of this year?

But anyway a lot of work is still being done on Futures 0.3 to include them in the standard library in their final form. I don't think it's wise to base something on it right now.

[prasannavl]

@OtaK true. I do agree with all of the above. However, following futures, in my opinion, I think it has gotten to a point of reasonable conceptual clarity. So, I think it would be a good starting point to explore the design.

And changes to futures from this point to stable is probably going to be on a progressive path without gross changes. Now, 0.2 would be an unreasonable ask. With 0.3, I think we can atleast start thinking about the design, and hence my proposition of alpha. But well, @fafhrd91 doesn't have the time right now anyway. So I suppose things will have to wait.

Currently, a quarter to half of the code I write in any small project with actix is just mapping errors, converting them back and forth. Essentially criss-crossing between the 3 paradigms in rust - Result, Option, and Future - is a pain. With 0.3+, the future having gotten rid of the error type, things will be lot more pleasant to work with, as Future's that return a result can just be unwrapped and dealt with as usual.

async/await anyway is just sugar. So, I don't think much, or if anything needs to be done about that. If it's follows a good design for future 0.3, async/await should just sit on top of it nicely.

[mehcode]

Check out https://github.com/mehcode/actix-web-async-await.

Primary motivation was so you could use async fn as handlers in Actix but it will also work if you have fn() -> impl std::future::Future handlers.

[fafhrd91]

added link to actix-web-async-await to readme

@mehcode

[mehcode]

@fafhrd91 Would it be possible to support handlers of the form:

use futures01::{future, Future}; // futures v0.1.x
use actix_web::{Path, error::Error, Responder};

fn handle(id: Path<u32>) -> impl Future<Item = impl Responder, Error = Error> {
    future::ok("Hello")
}

My guess is that this is complex because of the lack of stable specialization. We need to be able to support the above to allow bare async fns even if everything is switched over to futures 0.3 internally.

[fafhrd91]

@mehcode this is not possible without specialization or we would need to remove all Responder impls and leave only one for impl Future

[mehcode]

That's what I figured. Well it seems like this is a good use case to demonstrate more need for rust-lang/rust#31844.

I suspect a lot of libraries that want to take advantage of async fn are going to be blocked on this.

[prasannavl]

Lo and behold!
rust-lang/rfcs#2592

PS: I think one of the important and relevant comments: rust-lang/rfcs#2592 (comment)

[DoumanAsh]

Well I predict it means nothing yet until async/await is ready which is likely to happen in the next year

[fafhrd91]

closing as this issue is not actionable