Вы пробовали написать низкоуровневый код на расте без unsafe?
В чём смысл вопроса? unsafe для того и существует, чтобы предоставить программисту возможность реализовывать и самостоятельно проверять вещи, которые не способен проверить safe Rust, и изолировать эти вещи от остальной программы в этих самых unsafe-блоках (в околосишечных языках абсолютно весь код является unsafe, поэтому Rust тут безопаснее)
Может, потому что делать иначе просто нет смысла? Для немутабельной передачи с сохранением жизни исходной переменной уже есть передача по ссылке. А владение с запретом мутабельности для меня звучит как-то противоречиво, это уже как будто и не владение совсем
Ну теоретически всё ещё можно пробросить pub struct LambdaHolder или pub fn give_me_your_lambda в стороннюю библиотеку (но писать ещё один громоздкий пример я не буду)
А делать две разных логики для публичных и приватных функций — по-моему только ещё больше всех запутает
Я настолько глубоко не копал, но подозреваю, что компилятор просто не даст такое сделать
Строки, которые прописываются в строковых литералах (let s = "Hello, World!";) и предположительно будут помещены компилятором в сегмент данных, имеют другой тип &str — то есть ссылка на кусок строки без мутабельности (а точнее &'static str, что означает, что эта ссылка остаётся валидной в течение всей жизни программы)
Потому что программист так захотел и именно так объявил в сигнатуре функции
Как функция с иммутабельным параметром
(в случае иммутабельного параметра для начала)
Я тут у вас вижу повторяющееся заблуждение. Владелец параметра может делать с ним что угодно, в том числе превратить иммутабельное значение в мутабельное:
fn my_func(v: String) {
let mut v = v;
v.push_str("мутирую азаза");
}
Наличие или отсутствие мутабельности у значений — это больше защита от случайных опечаток, чтобы программист случайно не сделал то что изначально не планировал (но если всё же запланировал, то он может явно объявить мутабельность как в примере выше)
А вот мутабельность в ссылках это будет уже совсем другой разговор
После вызова my_func(s) владельцем параметра становится функция. Когда работа функции завершается, у параметра больше не остаётся владельца. Раз владельца больше нет — объект автоматически уничтожается и освобождается связанная с ним память. Этот факт защищает от утечек памяти, а невозможность использовать параметр повторно — от use-after-free
Вы хотите вывести сигнатуру функции из тела функции — это гиблый путь, при котором любое мелкое изменение в функции может сломать обратную совместимость
Именно! А это означает, что функция получает полное владение параметром и, если захочет, может уничтожить его. А значит из этой гарантии следует, что использовать параметр после вызова функции нельзя (иначе рискуем получить use-after-free).
В сигнатуре функции нет такой гарантии, будущие версии этой функции могут изменить своё поведение. Если программист хочет гарантировать, что строка будет жить после работы функции - он должен явно объявить такую гарантию в сигнатуре этой функции
И зачем?
Чтобы пользователь этой функции мог полагаться на явно объявленные гарантии, а не что-то там гадать про наличие или отсутствие долгов
В чём смысл вопроса? unsafe для того и существует, чтобы предоставить программисту возможность реализовывать и самостоятельно проверять вещи, которые не способен проверить safe Rust, и изолировать эти вещи от остальной программы в этих самых unsafe-блоках (в околосишечных языках абсолютно весь код является unsafe, поэтому Rust тут безопаснее)
Сочетание безопасности и скорости (языки с GC безопасные но медленные, околосишечные языки быстрые но небезопасные)
Во-первых, закон Мура вроде как несколько раз хоронили
Во-вторых, судя по этой фразе, именно из-за таких людей как вы появился закон Вирта)
Добавить libfoo в эти самые другие роли, не?
Может, потому что делать иначе просто нет смысла? Для немутабельной передачи с сохранением жизни исходной переменной уже есть передача по ссылке. А владение с запретом мутабельности для меня звучит как-то противоречиво, это уже как будто и не владение совсем
При передаче владения в подфункцию область жизни перемещается в эту самую подфункцию, вот и удаляется в конце области подфункции
Ну теоретически всё ещё можно пробросить
pub struct LambdaHolder
илиpub fn give_me_your_lambda
в стороннюю библиотеку (но писать ещё один громоздкий пример я не буду)А делать две разных логики для публичных и приватных функций — по-моему только ещё больше всех запутает
Я настолько глубоко не копал, но подозреваю, что компилятор просто не даст такое сделать
Строки, которые прописываются в строковых литералах (
let s = "Hello, World!";
) и предположительно будут помещены компилятором в сегмент данных, имеют другой тип&str
— то есть ссылка на кусок строки без мутабельности (а точнее&'static str
, что означает, что эта ссылка остаётся валидной в течение всей жизни программы)Ну, это не создаёт никаких уязвимостей, связанных с повреждением памяти, так что нет технических причин объявлять это unsafe ¯\_(ツ)_/¯
Лямбды тоже можно таскать глобально по всей программе
Потому что программист так захотел и именно так объявил в сигнатуре функции
Я тут у вас вижу повторяющееся заблуждение. Владелец параметра может делать с ним что угодно, в том числе превратить иммутабельное значение в мутабельное:
Наличие или отсутствие мутабельности у значений — это больше защита от случайных опечаток, чтобы программист случайно не сделал то что изначально не планировал (но если всё же запланировал, то он может явно объявить мутабельность как в примере выше)
А вот мутабельность в ссылках это будет уже совсем другой разговор
Так он есть прямо в посте:
После вызова
my_func(s)
владельцем параметра становится функция. Когда работа функции завершается, у параметра больше не остаётся владельца. Раз владельца больше нет — объект автоматически уничтожается и освобождается связанная с ним память. Этот факт защищает от утечек памяти, а невозможность использовать параметр повторно — от use-after-freeВы хотите вывести сигнатуру функции из тела функции — это гиблый путь, при котором любое мелкое изменение в функции может сломать обратную совместимость
Именно! А это означает, что функция получает полное владение параметром и, если захочет, может уничтожить его. А значит из этой гарантии следует, что использовать параметр после вызова функции нельзя (иначе рискуем получить use-after-free).
В сигнатуре функции нет такой гарантии, будущие версии этой функции могут изменить своё поведение. Если программист хочет гарантировать, что строка будет жить после работы функции - он должен явно объявить такую гарантию в сигнатуре этой функции
Чтобы пользователь этой функции мог полагаться на явно объявленные гарантии, а не что-то там гадать про наличие или отсутствие долгов
Посетители Хабра и так всё это прекрасно знают, а те, от кого вам приходят письма, эту недостатью всё равно не увидят
Тысячи уязвимостей в сишных программах наглядно демонстрируют что стоит
Ну вы лол конечно
Тогда почему такая проблема есть только у вас?
Ну значит у вас есть что-то другое, что отдаёт некорректные хостнеймы, иначе откуда их гугл взял бы