Plan: Rust 2024 prelude

[tmandry]

This is a roadmap item for wg-async. You can view the roadmap here: wg-async roadmap

[yoshuawuyts]

I'm currently thinking we should put the following traits forward for inclusion in the 2024 prelude:

• Future
• IntoFuture

This would mirror what we're including with Iterator / IntoIterator, and would hopefully be fairly uncontroversial. @rust-lang/wg-async WDYT?

[eholk]

Seems reasonable to me. I'm regularly surprised that Future isn't in the prelude.

A lot of code imports futures::Future. Would putting Future in the prelude break this code?

[yoshuawuyts]

A lot of code imports futures::Future. Would putting Future in the prelude break this code?

I don't believe so. They both point to the same trait, so with the way imports work this would Just Work I believe: playground.

[eholk]

Playing devil's advocate for a bit, are Future and IntoFuture traits that really need to be in the prelude? Most people don't implement Future directly, and probably even fewer call poll or into_future directly, so maybe it's reasonable to leave these as an advanced feature that people implementing low level async code import but most programmers don't use?

Put another way, what capabilities do we enable by putting them in the prelude?

(edit: accidentally said standard library instead of prelude in the first sentence. It's fixed now)

[Noah-Kennedy]

If not in the standard library, then where would they be?

[compiler-errors]

are Future and IntoFuture traits that really need to be in the standard library?

They certainly need to be in the standard library to support async and await desugaring.

Most people don't implement Future directly

Yeah, but I would assume more people using them as impl traits in return or arg position, like fn x() -> impl Future<Output = ..>, fn x(x: impl Future<Output = ..>) which would be helped by implementing

I can see how IntoFuture probably doesn't need to be in the prelude (since most people are just .awaiting on things), and I guess I could see Future also not being there.

[eholk]

Oh sorry, I misspoke! I meant to ask whether we need Future and IntoFuture in the prelude, not the standard library. I'll edit my comment.

[eholk]

Most people don't implement Future directly

Yeah, but I would assume more people using them as impl traits in return or arg position, like fn x() -> impl Future<Output = ..>, fn x(x: impl Future<Output = ..>) which would be helped by implementing

That's a good point.

I wonder what the bar is for including things in the prelude is? I'd assume it's for things that essentially all Rust programs will use. Almost every program uses Option and iterators, for example. There are still a sizeable number of programs that don't use async though and therefore don't need to use Future at all.

[nrc]

Yeah, we should talk to the libs team about criteria. Personally, I think we probably don't want to add anything - I reckon a minority of programs involves async code at all and a small minority of those write impl Future or implement a future because most just use async and await. Furthermore, those that do use explicit futures tend to just use them in a few places rather than everywhere, so importing them manually doesn't seem onerous. I think this all applies even more strongly to IntoFuture (aiui, the most common usage is implicitly in await where it doesn't need to be imported at all)

[yoshuawuyts]

I reckon a minority of programs involves async code at all and a small minority of those write impl Future or implement a future because most just use async and await.

This is something we can validate by searching GitHub:

• lang:rust /: Future/: yields 40.000 matches
• lang:rust /: Iterator/: yields 80.000 matches
• lang:rust /Future/ yields 700.000 matches
• lang:rust /Iterator/ yields 400.000 matches

GitHub code search does have a few limitations. For one the search is not case-sensitive. And it also includes lines which are part of comments. But if we interpret this as a rough indicator rather than a precise measurement, it would seem that Future is used about about half as often as iterator in bounds. And likely sees comparable usage elsewhere.

What I'm taking away from this is that the Future trait is probably used often enough that it would be justified for inclusion in the stdlib prelude. The most conservative interpretation of this is that Future is used about half as much as Iterator, one of the most used traits in the stdlib. By-volume that is a lot; and it would seem to me as enough to justify its inclusion. IntoFuture is most definitely used less than the other traits, but it's also only been part of stable Rust for months, not years like the other traits. At least to me it seems that if we're going to put up Future for consideration, IntoFuture should also just come with so it would continue mirroring the Iterator/IntoIterator trait set it was modeled after.

My goal with this comment was to specifically request input from the Async WG for which traits (or even types!) we may want to put forward for inclusion. Once we have a rough consensus among ourselves, I was planning to put it forward to the libs team as an ACP to formally clear the acceptance criteria with them.

[eholk]

It's possible that once we have AsyncIterator we may see Future used a lot more too, depending on how the API shapes up.