-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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 core::future::{poll_fn, PollFn} #72303
Conversation
r? @cramertj (rust_highfive has picked a reviewer for you, use r? to override) |
The job Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
The job Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
The job Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
cc/ @rust-lang/wg-async-foundations |
As with the other PR, I'm neutral-to-positive here. That is, I don't have a ton of hands-on experience using this helper, but I think including various utilities and helpers for authoring futures is pretty reasonable. |
|
@Koxiaet |
@taiki-e This function is a direct relationship with
|
@Koxiaet Description `iter` `future`
Direct function `from_fn` `poll_fn`
- Ends instantly `empty` `ready`/`lazy`
+ Ends instantly `empty` (none)
- Continues forever `repeat`/`repeat_with` `pending`
+ Continues forever `repeat`/`repeat_with` (none)
- Continues once `once`/`once_with` `yield`/`yield_with` (although these don't exist yet)
+ Continues once `once`/`once_with` `ready`/`lazy`
Also, since |
@taiki-e It depends on how you view futures; I made that table treating both as special cases of generators (Yield = T, Return = () for iterators and Yield = (), Return = T for futures):
Futures and iterators do have lots of similarities: both provide a sequence of one type terminated by a value of the other, where any further calls are likely to panic. As a result, both have |
@Dylan-DPC it's been a month since the last ping; perhaps we could get the same people that will review #70817 to also take a look at this? |
r? @dtolnay |
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.
This implementation has been modified from the implementation in
futures-rs
.
How has it been modified?
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.
This looks good to me. Thanks @yoshuawuyts!
@bors r+ |
📌 Commit a31f103 has been approved by |
🌲 The tree is currently closed for pull requests below priority 5, this pull request will be tested once the tree is reopened |
Add core::future::{poll_fn, PollFn} This is a sibling PR to rust-lang#70834, adding `future::poll_fn`. This is a small helper function that helps bridge the gap between "poll state machines" and "async/await". It was first introduced in [futures@0.1.7](https://docs.rs/futures/0.1.7/futures/future/fn.poll_fn.html) in December of 2016, and has been tried and tested as part of the ecosystem for the past 3.5 years. ## Implementation Much of the same reasoning from rust-lang#70834 applies: by returning a concrete struct rather than an `async fn` we get to mark the future as `Unpin`. It also becomes named which allows storing it in structs without boxing. This implementation has been modified from the implementation in `futures-rs`. ## References - [`futures::future::poll_fn`](https://docs.rs/futures/0.3.5/futures/future/fn.poll_fn.html) - [`async_std::future::poll_fn`](https://docs.rs/async-std/1.5.0/async_std/future/fn.poll_fn.html)
…arth Rollup of 19 pull requests Successful merges: - rust-lang#71322 (Accept tuple.0.0 as tuple indexing (take 2)) - rust-lang#72303 (Add core::future::{poll_fn, PollFn}) - rust-lang#73862 (Stabilize casts and coercions to `&[T]` in const fn) - rust-lang#73887 (stabilize const mem::forget) - rust-lang#73989 (adjust ub-enum test to be endianess-independent) - rust-lang#74045 (Explain effects of debugging options from config.toml) - rust-lang#74076 (Add `read_exact_at` and `write_all_at` to WASI's `FileExt`) - rust-lang#74099 (Add VecDeque::range* methods) - rust-lang#74100 (Use str::strip* in bootstrap) - rust-lang#74103 (Only add CFGuard on `windows-msvc` targets) - rust-lang#74109 (Only allow `repr(i128/u128)` on enum) - rust-lang#74122 (Start-up clean-up) - rust-lang#74125 (Correctly mark the ending span of a match arm) - rust-lang#74127 (Avoid "whitelist") - rust-lang#74129 (:arrow_up: rust-analyzer) - rust-lang#74135 (Update books) - rust-lang#74145 (Update rust-installer to latest version) - rust-lang#74161 (Fix disabled dockerfiles) - rust-lang#74162 (take self by value in ToPredicate) Failed merges: r? @ghost
This is a sibling PR to #70834, adding
future::poll_fn
. This is a small helper function that helps bridge the gap between "poll state machines" and "async/await". It was first introduced in futures@0.1.7 in December of 2016, and has been tried and tested as part of the ecosystem for the past 3.5 years.Implementation
Much of the same reasoning from #70834 applies: by returning a concrete struct rather than an
async fn
we get to mark the future asUnpin
. It also becomes named which allows storing it in structs without boxing. This implementation has been modified from the implementation infutures-rs
.References
futures::future::poll_fn
async_std::future::poll_fn