什么时候有必要规避 Rust 的借用检查器？

我正在实施康威的生命游戏来自学 Rust。我们的想法是首先实现单线程版本，尽可能优化它，然后对多线程版本执行相同的操作。

我想实现一种替代数据布局，我认为它可能对缓存更友好。这个想法是将板上每个点的两个单元的状态存储在向量中，一个单元用于读取当前一代的状态，一个单元用于写入下一代的状态，交替访问模式每个 生成的计算（可以在编译时确定）。

基本数据结构如下：

#[repr(u8)]
pub enum CellStatus {
    DEAD,
    ALIVE,
}

/** 2 bytes */
pub struct CellRW(CellStatus, CellStatus);

pub struct TupleBoard {
    width: usize,
    height: usize,
    cells: Vec<CellRW>,
}

/** used to keep track of current pos with iterator e.g. */
pub struct BoardPos {
    x_pos: usize,
    y_pos: usize,
    offset: usize,
}

pub struct BoardEvo {
    board: TupleBoard,
}

给我带来麻烦的功能：

impl BoardEvo {
    fn evolve_step<T: RWSelector>(&mut self) {
        for (pos, cell) in self.board.iter_mut() {
            //pos: BoardPos, cell: &mut CellRW
            let read: &CellStatus = T::read(cell); //chooses the right tuple half for the current evolution step
            let write: &mut CellStatus = T::write(cell);

            let alive_count = pos.neighbours::<T>(&self.board).iter() //<- can't borrow self.board again!
                    .filter(|&&status| status == CellStatus::ALIVE)
                    .count();

            *write = CellStatus::evolve(*read, alive_count);
        }
    }
}

impl BoardPos {
    /* ... */
    pub fn neighbours<T: RWSelector>(&self, board: &BoardTuple) -> [CellStatus; 8] {
        /* ... */
    }
}

特质RWSelector具有用于读取和写入单元元组的静态函数（CellRW）。它是针对两个零大小类型实现的L and R主要是避免为不同的访问模式编写不同的方法的一种方法。

The iter_mut()方法返回一个BoardIterstruct 是 cells 向量的可变切片迭代器的包装器，因此具有&mut CellRW as Item类型。也了解到目前的情况BoardPos（x 和 y 坐标，偏移量）。

我想我会迭代所有单元元组，跟踪坐标，计算每个（读取）单元的活动邻居的数量（我需要知道为此的坐标/偏移量），计算下一代的单元状态并写入元组各自的另一半。

当然，最后编译器向我展示了我的设计中的致命缺陷，正如我借用的self.board可变地在iter_mut()方法，然后尝试再次不可变地借用它以获取读取单元的所有邻居。

到目前为止我还没有能够想出一个好的解决方案来解决这个问题。我确实设法让它工作 引用不可变，然后使用UnsafeCell将对写入单元的不可变引用转变为可变引用。 然后，我通过以下方式写入对元组写入部分的名义上不可变的引用：UnsafeCell。 然而，这并不让我觉得是一个合理的设计，我怀疑在尝试并行化事物时可能会遇到问题。

有没有一种方法可以实现我在安全/惯用的 Rust 中提出的数据布局，或者这实际上是您必须使用技巧来规避 Rust 的别名/借用限制的情况？

另外，作为一个更广泛的问题，是否存在需要规避 Rust 借用限制的问题的可识别模式？

什么时候有必要规避 Rust 的借用检查器？

在以下情况下需要它：

• 借用检查器不够先进，无法确保您的使用是否安全
• 您不希望（或不能）以不同的模式编写代码

作为一个具体情况，编译器无法判断这是安全的：

let mut array = [1, 2];
let a = &mut array[0];
let b = &mut array[1];

编译器不知道执行了什么IndexMutfor a slice 在编译时执行此操作（这是经过深思熟虑的设计选择）。就其所知，无论索引参数如何，数组总是返回完全相同的引用。We可以看出这段代码是安全的，但编译器不允许它。

您可以以对编译器明显安全的方式重写它：

let mut array = [1, 2];
let (a, b) = array.split_at_mut(1);
let a = &mut a[0];
let b = &mut b[0];

这是怎么做到的？split_at_mut执行运行时检查 https://github.com/rust-lang/rust/blob/1.26.0/src/libcore/slice/mod.rs#L452-L462以确保它实际上is safe:

fn split_at_mut(&mut self, mid: usize) -> (&mut [T], &mut [T]) {
    let len = self.len();
    let ptr = self.as_mut_ptr();

    unsafe {
        assert!(mid <= len);

        (from_raw_parts_mut(ptr, mid),
         from_raw_parts_mut(ptr.offset(mid as isize), len - mid))
    }
}

例如，借用检查器不是yet尽可能先进，请参阅什么是非词汇生命周期？ https://stackoverflow.com/q/50251487/155423.

我借self.board可变地在iter_mut()方法，然后尝试再次不可变地借用它以获取读取单元的所有邻居。

如果您知道引用不重叠，那么您可以选择使用不安全代码来表达它。然而，这意味着you还选择承担维护 Rust 的所有不变量并避免未定义的行为 https://doc.rust-lang.org/reference/behavior-considered-undefined.html.

好消息是，这个沉重的负担是每个 C 和 C++ 程序员都必须承担的（或者至少是should）肩负着他们写的每一行代码。至少在 Rust 中，你可以让编译器处理 99% 的情况。

在许多情况下，有类似的工具Cell https://doc.rust-lang.org/std/cell/struct.Cell.html and RefCell https://doc.rust-lang.org/std/cell/struct.RefCell.html以允许内部突变。在其他情况下，您可以重写算法以利用作为Copy类型。在其他情况下，您可以在较短的时间内使用切片索引。在其他情况下，您可以采用多阶段算法。

如果您确实需要求助于unsafe代码，然后尽力将其隐藏在一个小区域并暴露安全的接口。

最重要的是，许多常见问题之前已经被问过（多次）：

• 如何在相同元素的另一个可变迭代中迭代可变元素？ https://stackoverflow.com/q/46003212/155423
• 改变嵌套循环内的项目 https://stackoverflow.com/q/29859892/155423
• 如何在 Rust 中实现 HashMap 上带有突变的嵌套循环？ https://stackoverflow.com/q/36281585/155423
• Rust 修改嵌套循环中的结构的方法是什么？ https://stackoverflow.com/q/29414171/155423
• 嵌套迭代器的循环 https://stackoverflow.com/q/38779588/155423