Skip to content
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

RFC: Include Future and IntoFuture in the 2024 prelude #3509

Merged
merged 3 commits into from
Feb 13, 2024

Conversation

yoshuawuyts
Copy link
Member

@yoshuawuyts yoshuawuyts commented Oct 7, 2023

Summary

This RFC describes the inclusion of the Future and IntoFuture traits 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

}
```

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:

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is this more similar to having IntoIterator in the prelude?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@alice-i-cecile that sounds like an argument for #1880 (inherent trait impls) instead of adding more symbols to the prelude.

@ehuss ehuss added the T-libs-api Relevant to the library API team, which will review and decide on the RFC. label Oct 7, 2023

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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.


## 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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

@ehuss ehuss added the A-edition-2024 Area: The 2024 edition label Nov 12, 2023
@tmandry
Copy link
Member

tmandry commented Jan 10, 2024

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 Amanieu added the I-libs-api-nominated Indicates that an issue has been nominated for prioritizing at the next libs-api team meeting. label Jan 19, 2024
@joshtriplett joshtriplett removed the I-libs-api-nominated Indicates that an issue has been nominated for prioritizing at the next libs-api team meeting. label Jan 23, 2024
@joshtriplett
Copy link
Member

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 IntoFuture.

@rfcbot
Copy link
Collaborator

rfcbot commented Jan 23, 2024

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 rfcbot added proposed-final-comment-period Currently awaiting signoff of all team members in order to enter the final comment period. disposition-merge This RFC is in PFCP or FCP with a disposition to merge it. labels Jan 23, 2024

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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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.

# 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:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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 rfcbot added final-comment-period Will be merged/postponed/closed in ~10 calendar days unless new substational objections are raised. and removed proposed-final-comment-period Currently awaiting signoff of all team members in order to enter the final comment period. labels Jan 23, 2024
@rfcbot
Copy link
Collaborator

rfcbot commented Jan 23, 2024

🔔 This is now entering its final comment period, as per the review above. 🔔

@rfcbot rfcbot added finished-final-comment-period The final comment period is finished for this RFC. to-announce and removed final-comment-period Will be merged/postponed/closed in ~10 calendar days unless new substational objections are raised. labels Feb 2, 2024
@rfcbot
Copy link
Collaborator

rfcbot commented Feb 2, 2024

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.

@Noratrieb
Copy link
Member

I created a tracking issue for this: rust-lang/rust#121042
And an implementation: rust-lang/rust#121041

All that's needed now is adding those links to the RFC, then we can merge it I think.

@ehuss ehuss merged commit 05a04ed into rust-lang:master Feb 13, 2024
@ehuss
Copy link
Contributor

ehuss commented Feb 13, 2024

Huzzah! The @rust-lang/libs-api team has decided to accept this RFC.

To track further discussion, subscribe to the tracking issue here:
rust-lang/rust#121042

@yoshuawuyts yoshuawuyts deleted the prelude-2024-future branch February 18, 2024 01:59
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Feb 19, 2024
… r=Mark-Simulacrum

Add `Future` and `IntoFuture` to the 2024 prelude

Implements rust-lang/rfcs#3509.
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Feb 19, 2024
… r=Mark-Simulacrum

Add `Future` and `IntoFuture` to the 2024 prelude

Implements rust-lang/rfcs#3509.
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request Feb 19, 2024
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-edition-2024 Area: The 2024 edition disposition-merge This RFC is in PFCP or FCP with a disposition to merge it. finished-final-comment-period The final comment period is finished for this RFC. T-libs-api Relevant to the library API team, which will review and decide on the RFC. to-announce
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.

10 participants