Tracking Issue for Ready::into_inner()

Feature gate: #![feature(ready_into_inner)]

This is a tracking issue for Ready::into_inner().

Adds a method to Ready that unwraps the value without an asynchronous context. See the futures library for an equivalent function.

Public API

impl<T> Ready<T> {
    #[must_use]
    #[inline]
    pub fn into_inner(self) -> T;
}

Steps / History

Implementation: Implement Ready::into_inner() #101189
Final comment period (FCP)¹
Stabilization PR: Stabilize Ready::into_inner() #116528

Unresolved Questions

None yet.

https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html ↩

Rollup merge of rust-lang#101189 - daxpedda:ready-into-inner, r=josht…

@joshtriplett

@joshtriplett would it be acceptable to start an FCP for this? Or are there any outstanding concerns?

@rfcbot

@rust-lang/libs-api:
@rfcbot fcp merge

Simple function for unpackaging a core::future::Ready<T> future that has not already been polled into a T.

The contentious part is that this can panic ("Called `into_inner()` on `Ready` after completion") which is unusual for a function named .into_inner(). This design is based on the identical API in the futures crate: https://docs.rs/futures/0.3.28/futures/future/struct.Ready.html#method.into_inner. It does not return Option<T>.

I feel this was addressed convincingly enough by #101189 (comment): "in the async world I have encountered the attitude that doing anything with a Future that was already polled to completion by returning Poll::Ready will panic". The next comment by a different user reinforces that -> T is frequently used while they have never seen a case that called for -> Option<T>.

ready.into_inner() is expressible in a more roundabout way (but still zero-cost, probably) by polling once with a noop waker. (Waker::noop() tracking issue: #98286. But you can write your own noop waker today on stable with some unsafe code.)

use core::future::{self, Future as _};
use core::pin::Pin;
use core::task::{Context, Poll, Waker};

let mut ready = future::ready(...);
let value = match Pin::new(&mut ready).poll(&mut Context::from_waker(&Waker::noop())) {
    Poll::Ready(ready) => ready,
    Poll::Pending => unreachable!(),
};

Be aware that a zero-cost conversion to Option<T> remains not expressible. If unwinding is enabled, one may use panic::catch_unwind(|| ready.into_inner()).ok(). Otherwise, someone with that use case will need to propose it under a different name — .take() was discussed for this in the implementation PR.

@dtolnay

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

Concerns:

~~async wg review~~ resolved by Tracking Issue for Ready::into_inner() #101196 (comment)

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.

cc @rust-lang/wg-async

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

@m-ou-se

Thanks for the ping @m-ou-se! - I am surprised to learn this API exists. Apparently WG Async hadn't been pinged on the implementation in #101189, and it never came up in any triage issue either. Can we please file a blocking concern on WG Async having a chance to discuss this in a meeting?

I don't know whether there are any issues, but I'd like to give ourselves some time to look this over and discuss it. Thank you!

@rfcbot

@rfcbot concern async wg review

@rfcbot

@rfcbot resolve async wg review

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

Which version is currently proposed? With all that back and forth I am confused which is current.

Ready<T>::unwrap() -> T
Ready<T>::into_inner() -> T
Ready<T>::into_inner() -> Option<T>

Currently in nightly appears to be 2. the stabilization PR currently includes changes to make it 1. and the discussion reads to me as if the current proposal is 3.

Number 2, I believe.

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.

Rollup merge of rust-lang#116528 - daxpedda:stabilize-ready-into-inne…

Auto merge of rust-lang#116528 - daxpedda:stabilize-ready-into-inner,…

Navigation Menu

Repository navigation

Tracking Issue for `Ready::into_inner()` #101196

Public API

Steps / History

Unresolved Questions

32 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Tracking Issue for Ready::into_inner() #101196

Description

Public API

Steps / History

Unresolved Questions

Footnotes

Activity

daxpedda commented on Jan 10, 2023

dtolnay commented on Oct 10, 2023

rfcbot commented on Oct 10, 2023

m-ou-se commented on Nov 7, 2023

rfcbot commented on Nov 7, 2023

yoshuawuyts commented on Nov 7, 2023

BurntSushi commented on Nov 7, 2023

32 remaining items

BurntSushi commented on Aug 6, 2024

rfcbot commented on Aug 6, 2024

Skgland commented on Aug 7, 2024

dtolnay commented on Aug 7, 2024

rfcbot commented on Aug 16, 2024

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Tracking Issue for `Ready::into_inner()` #101196