-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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 trait and support for await #65244
Conversation
This comment has been minimized.
This comment has been minimized.
r? @nikomatsakis cc @cramertj |
(My machine dies trying to compile rustc, so I'll be needing CI to tell me if I goofed a small thing. And I can add a tracking issue if accepted.) |
This comment has been minimized.
This comment has been minimized.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The code generally looks good to me -- though I feel like the test ought not to be passing. Let's see what travis says.
Anyway, the other question is whether we want to enable this. It'd be good to capture some of the motivation. The main thing I've heard (which I find persuasive) came from the async-finalizers blog post by @yoshuawuyts. The main reason I've heard for removing IntoFuture
was basically "YAGNI" -- not sure if there were more motivations than that? (Maybe @withoutboats remembers?)
src/libcore/future/future.rs
Outdated
@@ -99,6 +99,18 @@ pub trait Future { | |||
fn poll(self: Pin<&mut Self>, cx: &mut Context<'_>) -> Poll<Self::Output>; | |||
} | |||
|
|||
/// Conversion into a `Future`. | |||
#[unstable(feature = "into_future", issue = "0")] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should file a tracking issue, but let's hold off just a bit.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There should be a tracking issue before this gets merged, though, I think.
I don't think it was forgotten about-- |
@cramertj did you see the async-finalizers (since renamed to async-builders, I think) blog post I was referring to? That's at least one use case. (I'd like to know if @seanmonstar had another use case in mind, though!) |
Yes, I've long had various builders in reqwest and hyper that I've previously felt would be nice if they could easily become futures, but they themselves aren't futures. (My office internet is flaking hard, so might take a bit to update the PR.) |
a39ad71
to
ad8c47c
Compare
This comment has been minimized.
This comment has been minimized.
ad8c47c
to
4b7100f
Compare
This comment has been minimized.
This comment has been minimized.
bd3eb16
to
5e3d3bb
Compare
This comment has been minimized.
This comment has been minimized.
0b62bbe
to
3ecc4f7
Compare
3ecc4f7
to
f35517e
Compare
@bors r+ |
📌 Commit f35517e has been approved by |
add IntoFuture trait and support for await The [async-await RFC](https://rust-lang.github.io/rfcs/2394-async_await.html#the-await-compiler-built-in) mentions being able to `await` anything implementing `IntoFuture`. Somewhere along the way, it was left out.
Rollup of 15 pull requests Successful merges: - #65244 (add IntoFuture trait and support for await) - #67576 (reuse `capacity` variable in slice::repeat) - #67588 (Use NonNull in slice::Iter and slice::IterMut.) - #67594 (Update libc to 0.2.66) - #67602 (Use issue = "none" instead of "0" in intrinsics) - #67604 (Add Scalar::to_(u|i)16 methods) - #67617 (Remove `compiler_builtins_lib` documentation) - #67621 (Use the correct type for static qualifs) - #67629 (Remove redundant link texts) - #67632 (Convert collapsed to shortcut reference links) - #67633 (Update .mailmap) - #67635 (Document safety of Path casting) - #67654 (Add regression test for old NLL ICE) - #67659 (Stabilize the `matches!` macro) - #67664 (Fix some mailmap entries) Failed merges: r? @ghost
☔ The latest upstream changes (presumably #67670) made this pull request unmergeable. Please resolve the merge conflicts. |
Re-land "add IntoFuture trait and support for await" Testing the code from #65244 to see if the performance regressions are still there. #68606 and #68672 made perf optimizations that might interact with this change. If this lands, fixes #67982. cc @seanmonstar @jonas-schievink r? @cramertj
…akis Add core::future::IntoFuture This patch reintroduces the `core::future::IntoFuture` trait. However unlike earlier PRs this patch does not integrate it into the `async/.await` lowering since that lead to performance regressions. By introducing the trait separately from the integration, the integration PR can be more narrowly scoped, and people can start trying out the `IntoFuture` trait today. Thanks heaps! cc/ @rust-lang/wg-async-foundations ## References - Original PR adding `IntoFuture` rust-lang#65244 - Open issue to re-land `IntoFuture` (assigned to me) rust-lang#67982 - Tracking issue for `IntoFuture` rust-lang#67644
This is a reintroduction of the remaining parts from rust-lang#65244 that have not been relanded yet. Issues rust-langGH-67644, rust-langGH-67982
Reintroduce `into_future` in `.await` desugaring This is a reintroduction of the remaining parts from rust-lang#65244 that have not been relanded yet. This isn't quite ready to merge yet. The last attempt was reverting due to performance regressions, so we need to make sure this does not introduce those issues again. Issues rust-lang#67644, rust-lang#67982 /cc `@yoshuawuyts`
The async-await RFC mentions being able to
await
anything implementingIntoFuture
. Somewhere along the way, it was left out.