From a82d28221867a29d17358aff8284c58d100a7095 Mon Sep 17 00:00:00 2001 From: akulij Date: Wed, 19 Nov 2025 09:08:55 +0700 Subject: [PATCH 01/12] vault backup: 2025-11-19 09:08:55 --- 4.2/2.md | 1 + 1 file changed, 1 insertion(+) diff --git a/4.2/2.md b/4.2/2.md index e3f3db0..86c40e6 100644 --- a/4.2/2.md +++ b/4.2/2.md @@ -239,6 +239,7 @@ fn get_entities_at(entities: &mut [T], indices: [usize; N]) - } ``` Теперь гарантии происходят внутри самой функции. +Спустя некоторое время вам поступило ТЗ, что эта функция должна выдавать индексы только по энтити, **Начать с проблемы, когда компилятор не может гарантировать безопасность по памяти (но без этого невозможно написать программу), возможно из ub** Допустим, на вход вашей функции From 59ed7c0fede1315dd4ad29f76412345a5fc84558 Mon Sep 17 00:00:00 2001 From: akulij Date: Wed, 19 Nov 2025 09:12:26 +0700 Subject: [PATCH 02/12] vault backup: 2025-11-19 09:12:26 --- 4.2/2.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/4.2/2.md b/4.2/2.md index 86c40e6..912a3af 100644 --- a/4.2/2.md +++ b/4.2/2.md @@ -239,7 +239,9 @@ fn get_entities_at(entities: &mut [T], indices: [usize; N]) - } ``` Теперь гарантии происходят внутри самой функции. -Спустя некоторое время вам поступило ТЗ, что эта функция должна выдавать индексы только по энтити, +Спустя некоторое время вам поступило ТЗ, что эта функция должна выдавать индексы только по энтити, которые видимы (пускай будет трейт с методом is_visible). Изменим код: +**код** +Но останется ли такой код безопасным **Начать с проблемы, когда компилятор не может гарантировать безопасность по памяти (но без этого невозможно написать программу), возможно из ub** Допустим, на вход вашей функции From daf83819658f3962ca6a365e4fdec741ff2bc584 Mon Sep 17 00:00:00 2001 From: akulij Date: Wed, 19 Nov 2025 09:13:31 +0700 Subject: [PATCH 03/12] vault backup: 2025-11-19 09:13:31 --- 4.2/2.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/4.2/2.md b/4.2/2.md index 912a3af..84d3d89 100644 --- a/4.2/2.md +++ b/4.2/2.md @@ -239,9 +239,9 @@ fn get_entities_at(entities: &mut [T], indices: [usize; N]) - } ``` Теперь гарантии происходят внутри самой функции. -Спустя некоторое время вам поступило ТЗ, что эта функция должна выдавать индексы только по энтити, которые видимы (пускай будет трейт с методом is_visible). Изменим код: +Спустя некоторое время вашему коллеге поступило ТЗ, что эта функция должна выдавать индексы только по энтити, которые видимы (пускай будет трейт с методом is_visible). Изменим код: **код** -Но останется ли такой код безопасным +Но останется ли такой код безопасным? Читающему код придётся снова **Начать с проблемы, когда компилятор не может гарантировать безопасность по памяти (но без этого невозможно написать программу), возможно из ub** Допустим, на вход вашей функции From a732448748c8fe206d988c49f7f3027dfd0a4fa8 Mon Sep 17 00:00:00 2001 From: akulij Date: Wed, 19 Nov 2025 09:14:35 +0700 Subject: [PATCH 04/12] vault backup: 2025-11-19 09:14:35 --- 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 84d3d89..75edf5b 100644 --- a/4.2/2.md +++ b/4.2/2.md @@ -241,7 +241,7 @@ fn get_entities_at(entities: &mut [T], indices: [usize; N]) - Теперь гарантии происходят внутри самой функции. Спустя некоторое время вашему коллеге поступило ТЗ, что эта функция должна выдавать индексы только по энтити, которые видимы (пускай будет трейт с методом is_visible). Изменим код: **код** -Но останется ли такой код безопасным? Читающему код придётся снова +Но останется ли такой код безопасным? Читающему код придётся снова разбирать, какие инва **Начать с проблемы, когда компилятор не может гарантировать безопасность по памяти (но без этого невозможно написать программу), возможно из ub** Допустим, на вход вашей функции From 1115948c4629b64a3df8cfba763aaf0596cc33bb Mon Sep 17 00:00:00 2001 From: akulij Date: Wed, 19 Nov 2025 09:15:41 +0700 Subject: [PATCH 05/12] vault backup: 2025-11-19 09:15:41 --- 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 75edf5b..a0603ca 100644 --- a/4.2/2.md +++ b/4.2/2.md @@ -241,7 +241,7 @@ fn get_entities_at(entities: &mut [T], indices: [usize; N]) - Теперь гарантии происходят внутри самой функции. Спустя некоторое время вашему коллеге поступило ТЗ, что эта функция должна выдавать индексы только по энтити, которые видимы (пускай будет трейт с методом is_visible). Изменим код: **код** -Но останется ли такой код безопасным? Читающему код придётся снова разбирать, какие инва +Но останется ли такой код безопасным? Читающему код придётся снова разбирать, какие инварианты нужно соблюсти, чтобы код оставался безопасным. Но этого можно было бы избежать, если бы мы обозначали, какие инварианты мы соблюли, **Начать с проблемы, когда компилятор не может гарантировать безопасность по памяти (но без этого невозможно написать программу), возможно из ub** Допустим, на вход вашей функции From 09b46e3df0a8a1ed78b69e43706b96a658ad35b1 Mon Sep 17 00:00:00 2001 From: akulij Date: Wed, 19 Nov 2025 09:16:44 +0700 Subject: [PATCH 06/12] vault backup: 2025-11-19 09:16:44 --- 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 a0603ca..9b27f83 100644 --- a/4.2/2.md +++ b/4.2/2.md @@ -241,7 +241,7 @@ fn get_entities_at(entities: &mut [T], indices: [usize; N]) - Теперь гарантии происходят внутри самой функции. Спустя некоторое время вашему коллеге поступило ТЗ, что эта функция должна выдавать индексы только по энтити, которые видимы (пускай будет трейт с методом is_visible). Изменим код: **код** -Но останется ли такой код безопасным? Читающему код придётся снова разбирать, какие инварианты нужно соблюсти, чтобы код оставался безопасным. Но этого можно было бы избежать, если бы мы обозначали, какие инварианты мы соблюли, +Но останется ли такой код безопасным? Читающему код придётся снова разбирать, какие инварианты нужно соблюсти, чтобы код оставался безопасным. Но этого можно было бы избежать, если бы мы обозначали, какие инварианты мы соблюли. По примеру Safety у функций, у unsafe блоков обозна **Начать с проблемы, когда компилятор не может гарантировать безопасность по памяти (но без этого невозможно написать программу), возможно из ub** Допустим, на вход вашей функции From e11868e6da28554bcce806510db992bcf5e2e0fa Mon Sep 17 00:00:00 2001 From: akulij Date: Wed, 19 Nov 2025 09:17:49 +0700 Subject: [PATCH 07/12] vault backup: 2025-11-19 09:17:49 --- 4.2/2.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/4.2/2.md b/4.2/2.md index 9b27f83..d411337 100644 --- a/4.2/2.md +++ b/4.2/2.md @@ -241,7 +241,11 @@ fn get_entities_at(entities: &mut [T], indices: [usize; N]) - Теперь гарантии происходят внутри самой функции. Спустя некоторое время вашему коллеге поступило ТЗ, что эта функция должна выдавать индексы только по энтити, которые видимы (пускай будет трейт с методом is_visible). Изменим код: **код** -Но останется ли такой код безопасным? Читающему код придётся снова разбирать, какие инварианты нужно соблюсти, чтобы код оставался безопасным. Но этого можно было бы избежать, если бы мы обозначали, какие инварианты мы соблюли. По примеру Safety у функций, у unsafe блоков обозна +Но останется ли такой код безопасным? Читающему код придётся снова разбирать, какие инварианты нужно соблюсти, чтобы код оставался безопасным. Но этого можно было бы избежать, если бы мы обозначали, какие инварианты мы соблюли. По примеру Safety у функций, у unsafe блоков обозначают соблюдены инварианты словом SAFETY: +```rust +**Kod** +``` +Но, оно нужно не только **Начать с проблемы, когда компилятор не может гарантировать безопасность по памяти (но без этого невозможно написать программу), возможно из ub** Допустим, на вход вашей функции From 35d1537bcbf293ffc729c7bcb83fc1fd6659b5c4 Mon Sep 17 00:00:00 2001 From: akulij Date: Wed, 19 Nov 2025 09:19:02 +0700 Subject: [PATCH 08/12] vault backup: 2025-11-19 09:19:02 --- 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 d411337..4b703f0 100644 --- a/4.2/2.md +++ b/4.2/2.md @@ -245,7 +245,7 @@ fn get_entities_at(entities: &mut [T], indices: [usize; N]) - ```rust **Kod** ``` -Но, оно нужно не только +Но, оно нужно не только для этого. Такие комментарии помогают **Начать с проблемы, когда компилятор не может гарантировать безопасность по памяти (но без этого невозможно написать программу), возможно из ub** Допустим, на вход вашей функции From 41f6c241b134dd8e9099c53943ec38187e359e61 Mon Sep 17 00:00:00 2001 From: akulij Date: Wed, 19 Nov 2025 09:31:52 +0700 Subject: [PATCH 09/12] vault backup: 2025-11-19 09:31:52 --- 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 4b703f0..92b9a09 100644 --- a/4.2/2.md +++ b/4.2/2.md @@ -245,7 +245,7 @@ fn get_entities_at(entities: &mut [T], indices: [usize; N]) - ```rust **Kod** ``` -Но, оно нужно не только для этого. Такие комментарии помогают +Но, оно нужно не только для этого. При написании такого комментария программист лишний раз подумает, какие инварианты нужно соблюсти. А ещё, упрощает нахождение бага, так как можно сравнить условия, когда возникает баг, с теми условиями, что прописаны в комментариями. И баг по безопасности будет возникать возникать только в unsafe блоках. Правда, при всплытии в одном месте, причиной возникновения может стать unsafe блок в совершенно другом месте. Поэтому, **Начать с проблемы, когда компилятор не может гарантировать безопасность по памяти (но без этого невозможно написать программу), возможно из ub** Допустим, на вход вашей функции From cf0e32bb64d759ed72d3633ee4114a63ca018c56 Mon Sep 17 00:00:00 2001 From: akulij Date: Wed, 19 Nov 2025 09:37:22 +0700 Subject: [PATCH 10/12] vault backup: 2025-11-19 09:37:22 --- 4.2/2.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/4.2/2.md b/4.2/2.md index 92b9a09..eecbb81 100644 --- a/4.2/2.md +++ b/4.2/2.md @@ -245,7 +245,8 @@ fn get_entities_at(entities: &mut [T], indices: [usize; N]) - ```rust **Kod** ``` -Но, оно нужно не только для этого. При написании такого комментария программист лишний раз подумает, какие инварианты нужно соблюсти. А ещё, упрощает нахождение бага, так как можно сравнить условия, когда возникает баг, с теми условиями, что прописаны в комментариями. И баг по безопасности будет возникать возникать только в unsafe блоках. Правда, при всплытии в одном месте, причиной возникновения может стать unsafe блок в совершенно другом месте. Поэтому, +Но, оно нужно не только для этого. При написании такого комментария программист лишний раз подумает, какие инварианты нужно соблюсти. А ещё, упрощает нахождение бага, так как можно сравнить условия, когда возникает баг, с теми условиями, что прописаны в комментариями. И баг по безопасности будет возникать возникать только в unsafe блоках. Правда, при всплытии в одном месте, причиной возникновения может стать unsafe блок в совершенно другом месте. Поэтому, хотелось бы сузить количество кода для поиска бага, поэтому старайтесь уменьшать блоки unsafe. +### Хороший unsafe тот, который отсу **Начать с проблемы, когда компилятор не может гарантировать безопасность по памяти (но без этого невозможно написать программу), возможно из ub** Допустим, на вход вашей функции From b29d2cbeccbab6d3595d22a39eb274ede989c75b Mon Sep 17 00:00:00 2001 From: akulij Date: Wed, 19 Nov 2025 09:40:15 +0700 Subject: [PATCH 11/12] vault backup: 2025-11-19 09:40:15 --- 4.2/2.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/4.2/2.md b/4.2/2.md index eecbb81..e3e338e 100644 --- a/4.2/2.md +++ b/4.2/2.md @@ -246,7 +246,8 @@ fn get_entities_at(entities: &mut [T], indices: [usize; N]) - **Kod** ``` Но, оно нужно не только для этого. При написании такого комментария программист лишний раз подумает, какие инварианты нужно соблюсти. А ещё, упрощает нахождение бага, так как можно сравнить условия, когда возникает баг, с теми условиями, что прописаны в комментариями. И баг по безопасности будет возникать возникать только в unsafe блоках. Правда, при всплытии в одном месте, причиной возникновения может стать unsafe блок в совершенно другом месте. Поэтому, хотелось бы сузить количество кода для поиска бага, поэтому старайтесь уменьшать блоки unsafe. -### Хороший unsafe тот, который отсу +### Хорош тот unsafe, которого нет +Самую главную рекомендацию **Начать с проблемы, когда компилятор не может гарантировать безопасность по памяти (но без этого невозможно написать программу), возможно из ub** Допустим, на вход вашей функции From a1994f250efab5ed3d80397260a244ff91360312 Mon Sep 17 00:00:00 2001 From: akulij Date: Wed, 19 Nov 2025 09:45:31 +0700 Subject: [PATCH 12/12] 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** Допустим, на вход вашей функции