-
Notifications
You must be signed in to change notification settings - Fork 343
add IntoFuture #259
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
add IntoFuture #259
Conversation
Signed-off-by: Yoshua Wuyts <yoshuawuyts@gmail.com>
Signed-off-by: Yoshua Wuyts <yoshuawuyts@gmail.com>
|
Do you think it would make sense to open this PR in the rust-lang/rust repository? :) It seems to me the intention was for this trait to exist in the standard library, but nobody has implemented it there yet. |
|
@stjepang yeah I think it does. I do think there's value in still merging the PR here though. I'll check with the lang team what they think and if they're okay with it I'll follow up with the PR to std. |
|
@stjepang @yoshuawuyts I think |
|
There's now a PR to std for this also: rust-lang/rust#65244. |
301a506 to
9eab45f
Compare
Signed-off-by: Yoshua Wuyts <yoshuawuyts@gmail.com>
Adds the
IntoFuturetrait, wihch @Nemo157 pointed out would be useful for implementing the "async builder" pattern we used when building Surf.In the RFC2394 async_await it's also stated that
awaitshould callIntoFutureunder the hood.This PR doesn't add that functionality to
await, but does have the right shape it should take, which allows people to start implementingIntoFutureso that later it will "just work".cc/ @withoutboats, is what I've said so far about
IntoFuturestill accurate? I didn't see any mentions that this had been changed in the stabilization report, so does that mean that it means this simply has not been implemented yet?Screenshot