Tracking Issue for Cell::as_array_of_cells

[oconnor663]

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.

[pierzchalski]

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

[pierzchalski]

Wait, can I just do @rfcbot needs-fcp

[TOETOE55]

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);

[oconnor663]

@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?

[TOETOE55]

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>>) }
}

[RalfJung]

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

[Amanieu]

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.

[RalfJung]

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.

[TOETOE55]

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.

[RalfJung]

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

[TOETOE55]

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

sorry, my English is not very good, the comment has been edited.

[RalfJung]

yet arr_of_cells itself is not in an UnsafeCell, only its elements are.

Rust doesn't have an object model where there exists something like an "array object" that "contains" its fields or so. As far as Rust is concerned, an array is exactly the same thing as the collection of all its fields. So if call fields are fully covered by UnsafeCell, then so is the entire array.