Add AsyncFn* to the prelude in all editions

[compiler-errors]

The general vibe is that we will most likely stabilize the feature(async_closure) without the async Fn() trait bound modifier.

Without async Fn() bound syntax, this necessitates users to spell the bound like AsyncFn(). Since core::ops::AsyncFn is not in the prelude, users will need to import these any time they actually want to use the trait. This seems annoying, so let's add these traits to the prelude unstably.

We're trying to work on the general vision of async trait bound modifier in general in: rust-lang/rfcs#3710, however that RFC still needs more time for consensus to converge, and we've decided that the value that users get from calling the bound async Fn() is not really worth blocking landing async closures in general.

[rustbot]

r? @ibraheemdev

rustbot has assigned @ibraheemdev.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[traviscross]

@rfcbot fcp merge
@rustbot labels +I-lang-nominated +I-libs-api-nominated

With both the Fn traits and Future in the prelude (the latter in Rust 2024+), it makes a lot of sense to me to include these in the prelude also. There's no reason we can't include these traits in the prelude across all editions, especially by doing this at the time of stabilization, and so that seems best in terms of maximizing consistency across editions.

[rfcbot]

Team member @traviscross has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Amanieu
• @BurntSushi
• @dtolnay
• @joshtriplett
• @m-ou-se
• @nikomatsakis
• @pnkfelix
• @scottmcm
• @tmandry
• @traviscross

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!

cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
See this document for info about what commands tagged team members can give me.

[compiler-errors]

I wanted to note that, given that there are no stable methods or associated types on AsyncFn*, as far as I am aware there should not be any breakage due to adding these traits to the prelude on all editions.

Specifically, the method resolution problem with Future and any type-related import problems (e.g. with Cell) should not apply to this trait.

This is why I'm proposing to add AsyncFn* to all editions. Reducing edition-specific behavior is desirable in this case, even if we do expect that users will move onto edition 2024 soon after it is released.

[tmandry]

Yes, I think AsyncFn* (however we spell it) should be on par with the Fn* traits and we should put them in the prelude for every edition if possible.

@rfcbot reviewed

[nikomatsakis]

@rfcbot reviewed

[scottmcm]

How do I weigh this from a "profiles" sense? If using async.await means using https://docs.rs/futures/latest/futures/prelude/index.html in practice most of the time, for example, should this go there instead?

Or is it just "meh, whatever, I guess it doesn't really hard anything so fine"?

[compiler-errors]

If using async.await means using https://docs.rs/futures/latest/futures/prelude/index.html in practice most of the time, for example, should this go there instead?

I think it's a bit weird to expect users to import the prelude from a foreign crate to ergonomically use a lang feature, especially given we've put Future and IntoFuture into the prelude (in 2024, but only because of conflicts needing edition migration).

I think this deserves to be in the standard library's prelude.

[scottmcm]

I'm extremely ambivalent, but I don't want to block, so whatever, niko says I can check a box while abstaining.
@rfcbot reviewed

[rfcbot]

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

[nikomatsakis]

I am constantly surprised that Future is not in the prelude, given that it's a "core language feature". I just feels surprising to me that I can write async { } and get a future but I can't talk about impl Future without an import.

In the lang team discussion, @scottmcm also highlighted "convenient things that you need in the playground" (which would cover e.g. println!), and I think I would want AsyncFn from that perspective as well.

[rfcbot]

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.

[compiler-errors]

@rustbot ready

This could use a review, it's a pretty straightforward change :)

[ibraheemdev]

@bors r+

[bors]

📌 Commit 98b6e01 has been approved by ibraheemdev

It is now in the queue for this repository.

[bors]

⌛ Testing commit 98b6e01 with merge 4e4c20d...

[bors]

☀️ Test successful - checks-actions
Approved by: ibraheemdev
Pushing 4e4c20d to master...

[rust-timer]

Finished benchmarking commit (4e4c20d): comparison URL.

Overall result: ❌✅ regressions and improvements - no action needed

@rustbot label: -perf-regression

Instruction count

This is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	1.0%	[0.7%, 1.3%]	2
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-0.2%	[-0.2%, -0.2%]	1
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

Results (primary -3.4%, secondary 5.0%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	5.0%	[5.0%, 5.0%]	1
Improvements ✅ (primary)	-3.4%	[-3.4%, -3.4%]	1
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-3.4%	[-3.4%, -3.4%]	1

Cycles

Results (primary 3.5%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	3.5%	[3.5%, 3.5%]	1
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	3.5%	[3.5%, 3.5%]	1

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 796.612s -> 796.131s (-0.06%)
Artifact size: 336.26 MiB -> 336.32 MiB (0.02%)