Tracking issue for IntoFuture

[seanmonstar]

Introduced in #65244, this is a trait of a type that can be converted into a Future, used by .await (similar to how IntoIterator is used with for).

a more complete description can be found in #67644 (comment)

[Fishrock123]

Are there any blockers on this?

Surf would benefit from this, as presently, we use a kinda hacky work around with Options.

[Fishrock123]

cc @yoshuawuyts who may have some context

[Aaron1011]

This was implemented, but then reverted due to a performance regression. #69218 may help reduce the impact of implementing this.

[kushwahashiv]

how to use this in an app if I want to still use it

[kushwahashiv]

any update?

[ibraheemdev]

Trait was added back in #72459 and .await integration is tracked by #67982

[WaffleLapkin]

Just for a clarification (and to be similar to newer tracking issues)

---

Feature gate: #![feature(into_future)]

This is a tracking issue for the IntoFuture trait similar to IntoIterator allowing to convert types into futures.

Since #90737 this trait is also automatically used in expr.await desugaring allowing for code similar to the following (playground):

struct NotAFutureYet;

impl IntoFuture for NotAFutureYet {
    type Output = u8;
    type IntoFuture = Ready<Self::Output>;
    
    fn into_future(self) -> Self::IntoFuture {
        ready(42)
    }
}

async fn test() {
    assert_eq!(NotAFutureYet.await, 42);
}

Public API

// core::future

pub trait IntoFuture {
    type Output;
    type IntoFuture: Future<Output = Self::Output>;

    fn into_future(self) -> Self::IntoFuture;
}

Steps / History

• Implementation: Add core::future::IntoFuture #72459, Reintroduce into_future in .await desugaring #90737, Rename IntoFuture::Future to IntoFuture::IntoFuture #94818
• Final comment period (FCP)
• Stabilization PR

Unresolved Questions

• None yet.

[WaffleLapkin]

I wonder though if the method should be called into_fut to be more consistent with into_iter (note that it's not called into_iterator)

[yoshuawuyts]

I wonder though if the method should be called into_fut to be more consistent with into_iter (note that it's not called into_iterator)

@WaffleLapkin I don't think we should; "future" is a pretty short name already. The "iterator" submodule is named core::iter and the "future" submodule is named core::future. Even if we shorten "future" to "fut" for this API, we wouldn't be able to consistently match how it's used for iterator. I feel that inconsistency might throw people off, and it'd be better if we keep using "future" everywhere.

---

@rust-lang/libs-api now that #67982 has landed .await now desugars using IntoFuture as per RFC 2394. This means two years after the current version of IntoFuture landed on nightly the last blocker for it has been resolved!

I'd like to propose we FCP IntoFuture for stabilization. Rust 1.59 will be using the new .await desugaring, and it'd be great if the trait it desugars into is also available on stable.

[dtolnay]

👎 I'd veto stabilizing IntoFuture in the same release as the desugaring change. I don't know of any technical reason that the desugaring and trait benefit from being stabilized in the same release. I know the trait is old, but it hasn't been used in .await so far. Let's give users a chance to write code against this on nightly and uncover any resulting API awkwardness. The desugaring change can be amended or rolled back at any point because impl<F: Future> IntoFuture for F is the only impl built into core that a stable .await could make use of.

[yoshuawuyts]

@dtolnay that seems reasonable; happy to revisit this in a couple of months.

[yoshuawuyts]

@yaahc It appears both T-lang and T-libs-api members have been tagged on the merge proposal. In #67644 (comment) you mentioned that the right team to review this would be T-libs-api. Should T-lang be untagged?

[dtolnay]

Both is correct given that this affects meaning of .await language syntax.

[nikomatsakis]

@rfcbot reviewed

This is great, looking forward to this.

[yoshuawuyts]

ping @Amanieu, @cramertj, @m-ou-se - can I ask you to take a look at this when you have time?

[rfcbot]

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

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

[jonhoo]

I'm guessing this should be tagged with relnotes, or does to-announce already imply that?

[yaahc]

I'm guessing this should be tagged with relnotes, or does to-announce already imply that?

👍, David went and tagged the PR