Implement auto sending requests

[WaffleLapkin]

No description provided.

[hirrolot]

I'm worried about the technical debt that this PR would introduce because it comprises of lots of tricks and quite unintuitive control flow, despite of being working.

How about using a macro instead?

[playground]

macro_rules! send {
    ($req:expr) => {
        $req.send().await
    };
}

// Our hypothetical request.
struct Request;

impl Request {
    async fn send(self) -> i32 {
        123
    }
}

fn main() {
    let _123 = async {
        let req = Request;
        send!(req)
    };
}

It's a pity that we can't do req.send!() yet...

[hirrolot]

Also related to: rust-lang/rust#67982.

[WaffleLapkin]

I don't think that macro would accomplish much.

1. Macros are a bit scary. Personally, I expect that a macro will do something complicated and not just .await.send().
2. send!(...) vs ....send().await not much a difference (I would prefer the later...)

I also don't think that this code is too complicated. It just does simple bot-wrapper-things + implements Future for its request. Indeed this requires some minor tricks around Pin<_>, but they are ok, in my opinion.

[hirrolot]

I agree that send!(...) is not much better than ... .send().await, and moreover would necessitate deprecation of send! after the language issue above eventually resolves. In contrast, your PR plays nicely with the future directions of IntoFuture.

Concerning the PR code. I was confused that it uses unreachable expressions, but others conceived me that it's okay for Rusty futures, so nevermind.

[WaffleLapkin]

Well, if IntoFuture will support async/await just as IntoIterator+for then wrapper introduced in this PR will be useless too. We'll just add : IntoFuture bound for Request.

[hirrolot]

Well, if IntoFuture will support async/await just as IntoIterator+for then wrapper introduced in this PR will be useless too. We'll just add : IntoFuture bound for Request.

I understand; I meant that it would not break backward compatibility in user's code (at least in most cases).