История изменений
Исправление Siborgium, (текущая версия) :
В Rust так не принято.
Какая мне разница, что там принято? Я говорю – нет способа, вы мне – так не принято. Способа нет не потому, что так не принято, а потому что базовая модель не позволяет.
В коде реализации самого Rc никакого unsafe не будет
Нет, будет. От заворачивания в слои абстракции unsafe никуда не денется. Я бы понял, если бы вы говорили про unsafe для взаимодействия с платформозависимыми API – но речь об unsafe для реализации inner mutability, которая никак базовой моделью не предусматривается.
Суть Rust не в том, чтобы «писать без unsafe», а чтобы этот unsafe максимально изолировать.
Снова чушь. Вы можете изолировать unsafe только когда вы заворачиваете готовые интерфейсы, либо когда заворачиваете ради заворачивания. Попробуйте писать на Rust низкоуровневый код. Я пробовал – едет unsafe через unsafe. Заворачивать его бессмысленно, либо будет протекающая абстракция без реальных гарантий, либо ассерты на каждый вызов. У вас в невинном коде вида
fn do_something() -> Result<(), ()> {
if unsafe { !call_c_fn() } {
Ok(())
} else {
Err(())
}
}
fn main() {
if let Ok(_) = do_something() {
// ...
}
}
семантически вместо одного ветвления будет минимум два – внутри do_something и для того, чтобы сделать матч по результату. Ошибку принято пробрасывать вверх, поэтому там будет на каждом уровне еще по матчу. Что поделать – писать panic! с хэндлерами вместо исключений раст-библия не позволяет.
Это если отвечать на ваш аргумент, принимая, что вы почитали контекст и понимаете, на что отвечаете. Вы не понимаете.
Изначально я говорил о том, что базовая модель скудна, и никакой семантики счетчика ссылок (для компилятора) у Rc
нет, ее никак нельзя выразить. Более того, чтобы вообще написать Rc
, нужно показать компилятору, что вы умнее его и сами предоставите гарантии корректной работы Rc
, написав unsafe (неважно, на каком уровне). Ваши слова только подтверждают мой тезис.
Исходная версия Siborgium, :
В Rust так не принято.
Какая мне разница, что там принято? Я говорю – нет способа, вы мне – так не принято. Способа нет не потому, что так не принято, а потому что базовая модель не позволяет.
В коде реализации самого Rc никакого unsafe не будет
Нет, будет. От заворачивания в слои абстракции unsafe никуда не денется. Я бы понял, если бы вы говорили про unsafe для взаимодействия с платформозависимыми API – но речь об unsafe для реализации inner mutability, которая никак базовой моделью не предусматривается.
Суть Rust не в том, чтобы «писать без unsafe», а чтобы этот unsafe максимально изолировать.
Снова чушь. Вы можете изолировать unsafe только когда вы заворачиваете готовые интерфейсы, либо когда заворачиваете ради заворачивания. Попробуйте писать на Rust низкоуровневый код. Я пробовал – едет unsafe через unsafe. Заворачивать его бессмысленно, либо будет протекающая абстракция без реальных гарантий, либо ассерты на каждый вызов. У вас в невинном коде вида
fn do_something() -> Result<(), ()> {
if unsafe { !call_c_fn() } {
Ok(())
} else {
Err(())
}
}
fn main() {
if let Ok(_) = do_something() {
// ...
}
}
семантически вместо одного ветвления будет минимум два – внутри do_something и для того, чтобы сделать матч по результату. Ошибку принято пробрасывать вверх, поэтому там будет на каждом уровне еще по матчу. Что поделать – писать panic! с хэндлерами вместо исключений раст-библия не позволяет.
Это если отвечать на ваш аргумент, принимая, что вы почитали контекст и понимаете, на что отвечаете. Вы не понимаете.
Изначально я говорил о том, что базовая модель скудна, и никакой семантики счетчика ссылок (для компилятора) у Rc
нет, ее никак нельзя выразить. Более того, чтобы вообще написать Rc
, нужно показать компилятору, что ты умнее его и сам предоставишь гарантии корректной работы Rc
, написав unsafe (неважно, на каком уровне). Твои слова только подтверждают мой тезис.