Sketches for APIs involving Freeze.

[zachs18]

Let us assume that trait Freeze exists and means that a type has no interior mutability. What can we do with this?

Idea: Casting owned values or mutable references does not require Freeze, since they are unique and so no other code could change their value out from under us. Only casting shared references should require Freeze. (likewise, casting Box<T> and Vec<T> do not, but Rc<T> and Arc<T> do).

Hypothetical API change: AnyBitPattern/NoUninit/Pod no longer prohibit interior mutability. Instead, + Freeze bounds are put on all functions that cast shared data.

fn cast<T: NoUninit, U: AnyBitPattern>(t: T) -> U;
fn cast_mut<T: NoUninit + AnyBitPattern, U: NoUninit + AnyBitPattern>(t: &mut T) -> &mut U;
fn cast_ref<T: NoUninit + Freeze, U: AnyBitPattern + Freeze>(t: &T) -> &U;
// etc.

Edit: More formally, IIUC under stacked borrows, &T has SharedReadOnly permission if T: Freeze and SharedReadWrite otherwise(?). By requiring Freeze when casting &T, we prohibit casting between these permissions.
(Stacked borrows rules for Rc/Arc might be weird though idk)

[Lokathor]

Sounds right to me

[notgull]

It still feels kind of weird to cast interiorly mutable values around like this. While this may not be explicitly unsound, it just makes me worry that something might pop up in the future because of it. I feel like some aliasing guarantee or something. I don't know, someone smarter than me might have a better insight than my gut feeling.

[Lokathor]

But +Freeze on the bound is what makes the generic type not have interior mutability, so we still wouldn't be casting between having and not having interior mutability.

We also wouldn't even end up casting between one type of interior mutable to another.

[zachs18]

Now that trait Freeze is unstably public, I made a sketch of bytemuck using it https://github.com/zachs18/bytemuck/tree/v2-sketch