Tracking Issue for Cell::as_array_of_cells

Feature gate: #![feature(as_array_of_cells)]

This is a tracking issue for Cell::as_array_of_cells, the const-generic counterpart to the existing Cell::as_slice_of_cells.

Public API

impl<T, const N: usize> Cell<[T; N]> {
    pub const fn as_array_of_cells(&self) -> &[Cell<T>; N] { ... }
}

// Example

let mut array: [i32; 3] = [1, 2, 3];
let cell_array: &Cell<[i32; 3]> = Cell::from_mut(&mut array);
let array_cell: &[Cell<i32>; 3] = cell_array.as_array_of_cells();

Steps / History

Implementation: add Cell::as_array_of_cells, similar to Cell::as_slice_of_cells #87944
Final comment period (FCP)
Stabilization PR

Unresolved Questions

None yet.

@oconnor663

@oconnor663 Do you know who would be the right person to @ in order to get this reviewed/FCP'd? Given the existence of as_slice_of_cells I don't think we'll have a blocking discussion on the name or semantics, at least.

@rfcbot

Wait, can I just do @rfcbot needs-fcp

Does the following code violate the readonly constraint of arr_of_cells: &[Cell<i32>]?

 let mut arr = [0; 10];
 let cell_arr = Cell::from_mut(&mut arr);
 let arr_of_cells = cell_arr.as_array_of_cells();
 cell_arr.set([1; 10]);
// arr_of_cells was changed.
 dbg!(arr_of_cells);

@TOETOE55

@TOETOE55 Miri is ok with it at least. I could be totally wrong, but I think Miri sees these things in terms of bytes, and all the bytes in this case are covered by UnsafeCell, and that might be why it's ok.

@scottmcm what needs to be done to move to FCP?

The following code also passes Miri's checks
, but whether this should be UB is questionable. If I remember correctly, the current rule for the checks is that &T is readonly only when T does not contain UnsafeCell.

use core::cell::Cell;

fn main() {
    let mut opt = Some(1);
    let cell_opt = Cell::from_mut(&mut opt);
    let opt_cell = unsound(&cell_opt);
    dbg!(opt_cell.as_ref().unwrap());
    cell_opt.set(None);
    dbg!(opt_cell);
}

fn unsound<T>(opt: &Cell<Option<T>>) -> &Option<Cell<T>> {
    unsafe { &*(opt as *const Cell<Option<T>> as *const Option<Cell<T>>) }
}

@rust-lang/libs-api do you see any blockers for stabilizing this?

Does the following code violate the readonly constraint of arr_of_cells: &[Cell]?

No, this is fine -- you're only mutating things inside an UnsafeCell.

The following code also passes Miri's checks, but whether this should be UB is questionable.

Correct, but similar code can already be written with as_slice_of_cells. So, that's not really related to this tracking issue at all.

Rollup merge of rust-lang#131281 - RalfJung:const-cell, r=Amanieu

Unrolled build for rust-lang#131281

Should this be named transpose instead for consistency with the same method on MaybeUninit<[N; T]> and [MaybeUninit<T>; N]? It would also be an opportunity to introduce the reverse operation also named transpose.

I don't like transpose as a name, it says very little about what the operation actually does. as_slice_of_cells/as_array_of_cells is nicely explicit, which I think is a good thing.

Does the following code violate the readonly constraint of arr_of_cells: &[Cell]?

No, this is fine -- you're only mutating things inside an UnsafeCell.

What confuses me is that this code modifies arr_of_cells: &[Cell] through cell_arr: Cell<[i32; N]>, yet arr_of_cells itself is not in an UnsafeCell, only its elements are.

I'm afraid I cannot parse that sentence... " the arr_of_cell is not " is not what?

For the naming question, I think Cell::as_slice_of_cells has more consistency gravity for us here, since it's on the same type and it's also been stable for a long time? (MaybeUninit::transpose is still unstable.)

I didn't realize before, but there's also Result::transpose and Option::transpose. Though I feel it makes a lot more sense in those cases as any alternative along these lines (as_result_of_option???) would be somewhat "interesting" to understand upon first reading.
Though I still think as_slice_of_cells / as_array_of_cells are more straightforward in this case, maybe MaybeUninit::as_array_of_uninit and MaybeUninit::as_slice_of_uninit would be acceptable too?

For what it's worth, there's also a bit of sporadic discussion about the naming of MaybeUninit::transpose on the tracking issue, though I don't believe anybody has suggested the current style used here. I certainly think it would be nice if both APIs at least went the same direction.

My vibe-read is that MaybeUninit::transpose is probably on the way out, so would lean to not using it here. It does have the issue that without knowing exactly the types involved it's pretty opaque for what it's doing, which is fine sometimes, but less fine for unsafe-related things like MaybeUninit transformations where being more explicit than usual is often a good idea to avoid accidentally doing something might look right but accidentally uses the wrong type.

Rollup merge of rust-lang#144054 - jsimmons:stabilize-as-array-of-cel…

Unrolled build for #144054

Rollup merge of rust-lang#144054 - jsimmons:stabilize-as-array-of-cel…

Rollup merge of rust-lang#145504 - Jules-Bertholet:more_conversion_tr…

Unrolled build for #145504

Rollup merge of #145504 - Jules-Bertholet:more_conversion_trait_impls…

Navigation Menu

Repository navigation

Tracking Issue for Cell::as_array_of_cells #88248

Public API

Steps / History

Unresolved Questions

4 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Tracking Issue for Cell::as_array_of_cells #88248

Description

Public API

Steps / History

Unresolved Questions

Activity

pierzchalski commented on Aug 22, 2023

pierzchalski commented on Aug 27, 2023

TOETOE55 commented on Jan 9, 2024

oconnor663 commented on Jan 10, 2024

TOETOE55 commented on Jan 10, 2024

RalfJung commented on Oct 5, 2024

Amanieu commented on Oct 7, 2024

RalfJung commented on Oct 7, 2024

TOETOE55 commented on Oct 7, 2024

RalfJung commented on Oct 7, 2024

4 remaining items

jsimmons commented on Jul 17, 2025

scottmcm commented on Jul 20, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions