From a1994f250efab5ed3d80397260a244ff91360312 Mon Sep 17 00:00:00 2001 From: akulij Date: Wed, 19 Nov 2025 09:45:31 +0700 Subject: [PATCH] vault backup: 2025-11-19 09:45:31 --- 4.2/2.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/4.2/2.md b/4.2/2.md index e3e338e..308b22c 100644 --- a/4.2/2.md +++ b/4.2/2.md @@ -247,7 +247,7 @@ fn get_entities_at(entities: &mut [T], indices: [usize; N]) - ``` Но, оно нужно не только для этого. При написании такого комментария программист лишний раз подумает, какие инварианты нужно соблюсти. А ещё, упрощает нахождение бага, так как можно сравнить условия, когда возникает баг, с теми условиями, что прописаны в комментариями. И баг по безопасности будет возникать возникать только в unsafe блоках. Правда, при всплытии в одном месте, причиной возникновения может стать unsafe блок в совершенно другом месте. Поэтому, хотелось бы сузить количество кода для поиска бага, поэтому старайтесь уменьшать блоки unsafe. ### Хорош тот unsafe, которого нет -Самую главную рекомендацию +Лучшее, что можно сделать с unsafe: это не писать его. Если ту же логику можно можно написать в safe rust, то пишите её в safe rust (разве что, можно как небольшое исключение сказать про случай, когда с unsafe мы можем получить хороший прирост производительности в критическом для производительности месте). Стоит что раз подумать, прежде чем писать unsafe код. **Начать с проблемы, когда компилятор не может гарантировать безопасность по памяти (но без этого невозможно написать программу), возможно из ub** Допустим, на вход вашей функции