Блог*

#prog #rust #моё В конце этой заметки я сказал, что планирую расширить код до поддержки impl BorrowMut<VecDeque<T>>. Теперь я понимаю, что это несколько неосмотрительно: код в unsafe полагается на то, что адрес, по которому лежат данные, не меняется. В случае…

#prog #rust #моё
Сообщаю, что данную проблему я решил, воспользовавшись несколько модифицированной версией идеи №3. Ссылка на гист та же самая, но для удобства я её продублирую: https://gist.github.com/AnthonyMikh/bb41179b20938ba329c3d411ddc1c679 (чтобы посмотреть на то, как файл выглядел в изначальном посте, откройте вторую версию). В данный момент MutPair имеет следующий вид:

    pub struct Original;
    pub struct View;

    pub struct MutPair<T, Deq = VecDeque<T>, Idx = usize, Kind = Original> {
        inner: Deq,
        first: Idx,
        _type: PhantomData<(T, Kind)>,
    }

Такое замысловатое определение позволяет расширить возможности, предоставляемые API.

1) Каким образом решена проблема злонамеренного BorrowMut? Очень просто: публичные методы дают возможность создать только MutPair с Deq, являющимся VecDeque<T> и &mut VecDeque<T>, поэтому все сложности, связанные с нестабильностью адресов слайсов, отпадают.
2) Почему для индексов не используется usize? Дело в том, что у владеющего MutPair теперь есть два метода, которые создают MutPair, держащие ссылку на дек. Один из них (создаваемый методом view) работает, как ожидается, а второй, создаваемый методом linked_view, при вызове методов step_right/step_left также меняет позицию изначального MutPair. Для того, чтобы поддержать этот случай использования, имеется возможность использовать как usize, так и &mut usize.
3) Зачем вообще нужен параметр Kind? Дело в том, что, как я уже подчёркивал, memory safety данного кода существенным образом опирается на невозможность поменять длину дека. Как для владеющего, так и для заимствующего MutPair имеет смысл операция into_inner, которая отдаёт дек, но безусловное разрешение подобного метода даёт возможность написать некорректный код с использованием безопасного API (я, к своему стыду, изначально допустил эту ошибку):

let deque = ...;
let mut owning_pair = MutPair::try_from(deque).unwrap();
let mut pair = owning_pair.view();
let mut deque = view.into_inner();
deque.clear();
let _ = owning_pair.get(); // Hello UB!

Таким образом, into_inner для заимствующего MutPair безопасен только при условии, что объект построен из ссылки на дек непосредственно, а не получен из владеющего MutPair. Именно это ограничение и обеспечивается четвёртым ти́повым параметром: методы view/linked_view возвращают MutPair с Kind = View, в то время как метод into_inner определён лишь для MutPair с Kind = Original.

Gist

Mutable view for VecDeque

Mutable view for VecDeque. GitHub Gist: instantly share code, notes, and snippets.

265 viewsedited 20:56