Tracking Issue for lazy_cell_into_inner

[tspiteri]

This superceded #109736 now that the lazy_cell feature has been stabilized.

Feature gate: #[feature(lazy_cell_into_inner)]

This is a tracking issue for LazyCell::into_inner and LazyLock::into_inner.

Public API

// core::cell (in core/src/cell/lazy.rs)

impl<T, F: FnOnce() -> T> LazyCell<T, F> {
    pub const fn into_inner(this: Self) -> Result<T, F>;
}

// std::sync (in std/sync/lazy_lock.rs)

impl<T, F: FnOnce() -> T> LazyLock<T, F> {
    pub fn into_inner(this: Self) -> Result<T, F>;
}

Steps / History

• Implementation: Add LazyCell::into_inner #106152
• Final comment period (FCP)¹
• Stabilization PR

Unresolved Questions

• None yet.

Footnotes

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

[workingjubilee]

@tspiteri Would you be so kind as to make the tracking issue? (you could even just edit this one) We can edit it from there if we need to change things.

[tgross35]

Could this be renamed to lazy_cell_into_inner? I keep thinking this is is referencing an API that uses atomic consume operations, which was discussed for the implementation of OnceLock/LazyLock but ultimately rejected (e.g. here).

[workingjubilee]

Go for it.

[tgross35]

I was mostly asking for someone to rename the issue, but here we go #127599. Rustbot has really been spot on picking reviewers for me recently.

[tgross35]

Could this be considered for stabilization? This serves the same purpose as into_inner methods available on other cell and sync types, and the signature is consistent with once_cell's Lazy::into_value.

The only downside I see here is that .unwrap() doesn't work since the closure doesn't implement Debug.

@rustbot label +I-libs-api-nominated

[Amanieu]

We discussed this in the libs-api meeting. The use case for this method wasn't very clear and returning F as an error type seems awkward as it doesn't implement Debug (consider the signature of BufWriter::into_inner for comparison).

Since the initialization function is infallible, we wondered if a force_into function wouldn't be a better fit for use cases in practice.

[joshtriplett]

To the extent people do need the method that returns the closure, that method might make sense to call into_parts, and use a dedicated enum rather than using Result.