4:19

4:20

#article
Перевод подъехал
https://habr.com/ru/post/485044/

Пофиксили и портировали на бета-версию: https://github.com/rust-lang/rust/issues/67083#issuecomment-577747665

#politota

Очень интересно

https://www.vedomosti.ru/technology/articles/2020/01/23/821333-duhovno-nravstvennie-tsennosti

"Формировать список типов ПО, разрешенного для предустановки, будет ФАС совместно с Минкомсвязи и Роспотребнадзором, а утверждать – правительство. Чтобы попасть в него, программа должна разрабатываться в России, быть совместимой с системным софтом, на базе которого работает устройство, и бесплатной для пользователей, а также не должна содержать «недокументированных возможностей»"

То есть пасхалок в играх не будет

Картинка смешная, а ситуация страшная

История URL для документации к Rust std-либе:
doc.rust-lang.org/std
⬇️
docs.rs/std
⬇️
std.rs

#quotes #rust #haskell #meme

придумал хаскель-версию

#prog #rust #amazingopensource

Ссылка на итоговый код: https://github.com/Nachasic/machine/blob/raylib/src/theme/mod.rs

https://t.me/rustlang_ru/271888

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

И да, я опять немного побрюзжу: этот код было бы проще написать, будь у VecDeque адаптер, гарантирующий стабильные адреса. Я думал о том, чтобы написать такой адаптер самому, но потом понял, что с нормальными гарантиями такой адаптер может написать только автор кода VecDeque, который знает внутреннее устройство и может точно сказать, какие методы не перемещают данные — собственно, в этом смысле сейчас безопасность кода базируется на допущениях, который верны сейчас, но в силу отсутствия явных контрактов могут стать неверными в будущих релизах std

#meme со звёздочкой