Tracking Issue for const_cell

[RalfJung]

Feature gate: #![feature(const_cell)]

This is a tracking issue for using Cell in a const context.

Public API

// core::cell

impl<T> Cell<T> {
    pub const fn replace(&self, val: T) -> T;
}

impl<T: Copy> Cell<T> {
    pub const fn get(&self) -> T;
}

impl<T: ?Sized> Cell<T> {
    pub const fn get_mut(&mut self) -> &mut T;
    pub const fn from_mut(t: &mut T) -> &Cell<T>;
}

impl<T> Cell<[T]> {
    pub const fn as_slice_of_cells(&self) -> &[Cell<T>];
}

Steps / History

• Implementation: make Cell unstably const #131281
• Final comment period (FCP)¹
• Stabilization PR

Unresolved Questions

• None yet.

Footnotes

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

[RalfJung]

@rust-lang/libs-api @rust-lang/wg-const-eval I see no reason to wait any longer, so I propose we stabilize the use of Cell in const fn -- specifically the APIs listed here:

// core::cell

impl<T> Cell<T> {
    pub const fn replace(&self, val: T) -> T;
}

impl<T: Copy> Cell<T> {
    pub const fn get(&self) -> T;
}

impl<T: ?Sized> Cell<T> {
    pub const fn get_mut(&mut self) -> &mut T;
    pub const fn from_mut(t: &mut T) -> &Cell<T>;
}

impl<T> Cell<[T]> {
    pub const fn as_slice_of_cells(&self) -> &[Cell<T>];
}

Unfortunately, set cannot be made const fn yet as it drops the old contents.

[traviscross]

In the libs-api call last week, we (mostly @Amanieu and I) talked about and agreed on doing libs-api stabilization FCPs on the stabilization PRs rather than on the tracking issues. This lets the team look at exactly what will be stabilized, it helps avoid the skew that can sometimes happen between what gets FCPed and what goes up in the PR, and it aligns the process with what lang does. While the risk of skew seems low in this particular case, perhaps it'd be better to go ahead and put up the stabilization PR for this and nominate that.

As you say, it does seem time to do these.

[RalfJung]

Okay, I will prepare a PR when I find some time.

The library tracking issue template should then be adjusted to make it clear that the FCP should happen in the stabilization PR :)

[RalfJung]

PR is up at #137928

[moxian]

@traviscross should the documentation at https://rustc-dev-guide.rust-lang.org/stability.html#stabilizing-a-library-feature be updated to reflect this new policy? Or is it still in the "experimental" and "on a case-by-case basis" state?

[traviscross]

Probably it should, yes.

(It's @Amanieu's call, but he seemed settled on it when we talked. We discussed whether any documentation would need to be updated, but that page and the tracking issue template didn't immediately come to mind, so we both just agreed we'd start to tell people to do it this way.)