RFC: Include Future and IntoFuture in the 2024 prelude
#3509
Conversation
0000-prelude-2024-future.md
Outdated
| } | ||
| ``` | ||
|
|
||
| In the Rust 2021 edition this code would require an explicit import of the `IntoFuture` trait. When migrating to the 2024 edition the import of the `IntoFuture` trait would be taken care of by the prelude, and the code could remove the explicit import: |
There was a problem hiding this comment.
This doesn't feel like the strongest example. Generally I find that traits are most useful in preludes when you want to implicitly use their methods. Are there applications like that?
There was a problem hiding this comment.
is this more similar to having IntoIterator in the prelude?
There was a problem hiding this comment.
Yeah, exactly. Being able to always call .into_iter() is really useful. Being able to return a impl IntoIterator or create a Box<dyn IntoIterator> is moderately useful, but nowhere near as valuable, both in terms of frequency and beginner-accessiblity.
There was a problem hiding this comment.
Looks like poll is the only method. Hmm, not actually sure which one is more useful to show off. I guess you could do both.
There was a problem hiding this comment.
@alice-i-cecile that sounds like an argument for #1880 (inherent trait impls) instead of adding more symbols to the prelude.
ehuss
added
the
T-libs-api
0000-prelude-2024-future.md
Outdated
|
|
||
| Both the `Future` and `IntoFuture` definitions in the standard library are considered _canonical_: there exist no widespread alternative definitions in the Rust ecosystem. Simply having both traits in scope is unlikely to lead to any issues, and the only likely noticable outcome is that authoring async code will require slightly less effort. | ||
|
|
||
| # Rationale and alternatives |
There was a problem hiding this comment.
I think it'd be good to add a "Do nothing" section as an alternative. This is kind of addressed elsewhere in the RFC (limited expected breakage and async code is slightly harder to write), but having it called out into its own section would be helpful.
0000-prelude-2024-future.md
Outdated
|
|
||
| ## Include `Future` in 2024, re-consider `IntoFuture` in 2027 | ||
|
|
||
| This RFC takes what could be called a: _"systems-based perspective"_. We're arguing that the core property which qualifies the `Future` and `IntoFuture` traits for inclusion in the prelude is their fundamental relationship to the language. Similar to how `Iterator` and `Result` correspond to core control-flow effects, `Future` and `IntoFuture` do too. |
There was a problem hiding this comment.
Does the systems-based justification work for other things that are in the prelude currently? In other words, have we used this justification before, even if we may not have had a name for it?
|
Hey @rust-lang/libs-api, it would be great to consider this for the 2024 edition. I believe this should be a purely libs decision (and not lang), do you agree? |
Amanieu
added
the
I-libs-api-nominated
joshtriplett
removed
the
I-libs-api-nominated
|
We discussed this in today's @rust-lang/libs-api meeting, and agreed to start the merge process: @rfcbot merge I'm going to submit a suggestion to improve the rationale for |
|
Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members: No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See this document for info about what commands tagged team members can give me. |
rfcbot
added
proposed-final-comment-period
0000-prelude-2024-future.md
Outdated
|
|
||
| When an `async fn` is desugared we obtain an anonymous type with a signature of `impl Future`. In order to use this type we must first be able to _name_ it, which can only be done if the `Future` trait in scope. Currently this can be a little inconvenient since it requires `std::future::Future` to be manually imported. | ||
|
|
||
| Most other reifications of control-flow effects have their respective types and traits included in the prelude header. To support iteration we include both the `Iterator` and `IntoIterator` traits in the prelude. To support fallibility we include both `Option` and `Result` in the prelude. This RFC proposes we include both `Future` and `IntoFuture` to match. |
There was a problem hiding this comment.
| Most other reifications of control-flow effects have their respective types and traits included in the prelude header. To support iteration we include both the `Iterator` and `IntoIterator` traits in the prelude. To support fallibility we include both `Option` and `Result` in the prelude. This RFC proposes we include both `Future` and `IntoFuture` to match. | |
| `IntoFuture` comes up regularly when writing operations that accept a `Future`. Adding `IntoFuture` makes it easy to call `.into_future()` to bridge between code accepting only `Future` and code supplying an `IntoFuture` impl, as well as making it easy to write new code that accepts any `IntoFuture` impl. | |
| Both of these traits are generally useful, come up regularly, don't conflict with anything, and will not produce any surprising behavior if added to the prelude. | |
| Most other reifications of control-flow effects have their respective types and traits included in the prelude header. To support iteration we include both the `Iterator` and `IntoIterator` traits in the prelude. To support fallibility we include both `Option` and `Result` in the prelude. This RFC proposes we include both `Future` and `IntoFuture` to match. |
0000-prelude-2024-future.md
Outdated
| # Guide-level explanation | ||
| [guide-level-explanation]: #guide-level-explanation | ||
|
|
||
| Let's say someone wrote an async function which takes a future and operates on it. For example, it could be something like this: |
There was a problem hiding this comment.
| Let's say someone wrote an async function which takes a future and operates on it. For example, it could be something like this: | |
| In Rust 2024, you can name and make use of the `Future` and `IntoFuture` traits without explicitly importing them, since they appear in the Rust 2024 prelude. For instance, you can write a function that accepts or returns an `impl Future`, or one that accepts any `impl IntoFuture`. | |
| Let's say someone wrote an async function which takes a future and operates on it. For example, it could be something like this: |
rfcbot
added
final-comment-period
|
🔔 This is now entering its final comment period, as per the review above. 🔔 |
rfcbot
added
finished-final-comment-period
|
The final comment period, with a disposition to merge, as per the review above, is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. This will be merged soon. |
|
I created a tracking issue for this: rust-lang/rust#121042 All that's needed now is adding those links to the RFC, then we can merge it I think. |
|
Huzzah! The @rust-lang/libs-api team has decided to accept this RFC. To track further discussion, subscribe to the tracking issue here: |
… r=Mark-Simulacrum Add `Future` and `IntoFuture` to the 2024 prelude Implements rust-lang/rfcs#3509.
… r=Mark-Simulacrum Add `Future` and `IntoFuture` to the 2024 prelude Implements rust-lang/rfcs#3509.
Rollup merge of rust-lang#121041 - Nilstrieb:into-the-future-of-2024, r=Mark-Simulacrum Add `Future` and `IntoFuture` to the 2024 prelude Implements rust-lang/rfcs#3509.
Summary
This RFC describes the inclusion of the
FutureandIntoFuturetraits in the 2024 edition prelude.Rendered
This is a continuation of rust-lang/wg-async#310. It depends on #3501 being accepted first.
cc/ @rust-lang/wg-async @rust-lang/libs-api