Open
Description
This is a roadmap item for wg-async. You can view the roadmap here: wg-async roadmap
Metadata
Metadata
Assignees
Labels
No labels
Type
Projects
Status
Relationships
Development
No branches or pull requests
This is a roadmap item for wg-async. You can view the roadmap here: wg-async roadmap
Status
Activity
yoshuawuyts commentedon Mar 29, 2023
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 commentedon Mar 29, 2023
Seems reasonable to me. I'm regularly surprised that
Future
isn't in the prelude.A lot of code imports
futures::Future
. Would puttingFuture
in the prelude break this code?yoshuawuyts commentedon Mar 30, 2023
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 commentedon Mar 30, 2023
Playing devil's advocate for a bit, are
Future
andIntoFuture
traits that really need to be in the prelude? Most people don't implementFuture
directly, and probably even fewer callpoll
orinto_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 commentedon Mar 30, 2023
If not in the standard library, then where would they be?
compiler-errors commentedon Mar 30, 2023
They certainly need to be in the standard library to support
async
andawait
desugaring.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 implementingI can see how
IntoFuture
probably doesn't need to be in the prelude (since most people are just.await
ing on things), and I guess I could seeFuture
also not being there.eholk commentedon Mar 30, 2023
Oh sorry, I misspoke! I meant to ask whether we need
Future
andIntoFuture
in the prelude, not the standard library. I'll edit my comment.eholk commentedon Mar 30, 2023
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 useFuture
at all.nrc commentedon Mar 30, 2023
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 inawait
where it doesn't need to be imported at all)yoshuawuyts commentedon Mar 31, 2023
This is something we can validate by searching GitHub:
lang:rust /: Future/
: yields 40.000 matcheslang:rust /: Iterator/
: yields 80.000 matcheslang:rust /Future/
yields 700.000 matcheslang:rust /Iterator/
yields 400.000 matchesGitHub 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 thatFuture
is used about half as much asIterator
, 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 upFuture
for consideration,IntoFuture
should also just come with so it would continue mirroring theIterator
/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 commentedon Mar 31, 2023
It's possible that once we have
AsyncIterator
we may seeFuture
used a lot more too, depending on how the API shapes up.8 remaining items