Потому что правила автовывода лайтаймов (lifetime elision) строго определены, и данный случай под эти правила не подходит.
Вот пример кода, где выставление одинакового лайфтайма (времени жизни, ВЖ) во всех местах в функции foo_incorrect не пройдет проверку БЧ (borrow checker):
// https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=1ce9cb09c241bf12fba2bd33574b24b0
fn main() {
let mut str_mut = "";
let s1 = String::from("str1");
{
let s2 = String::from("str2");
str_mut = foo_incorrect(&s1, &s2); // fail here
// str_mut = foo_correct(&s1, &s2); // will be ok
}
println!("{str_mut}");
}
fn foo_correct<'long, 'short>(a: &'long str, b: &'short str) -> &'long str {
todo!()
}
fn foo_incorrect<'a>(a: &'a str, b: &'a str) -> &'a str {
todo!()
}
Надо понимать, что БЧ выполняет проверку ВЖ для каждой функции отдельно, не заглядывая в тела других использующихся функций. То есть, в примере выше - неважно что будет написано в теле функций foo_correct \ foo_incorrect - проверка ВЖ для функции main от этого никак не изменится: учитываться будут только сигнатуры вызываемых функций.
Если бы для каждой функции анализировались тела всех используемых функций, то время компиляции стремилось бы к бесконечности. Но что хуже - такое поведение вносило бы гораздо больше ошибок из-за неправильного вывода ВЖ. Даже стандартные правила вывода ВЖ иногда приводят к неверному результату, приходится вручную указывать (но это редко).
Компилятор не может знать что вы хотите написать, он может только проверить на корректность написанное.
Управление памятью реализовано через владение (ownership). Компилятор на этапе _компиляции_ анализирует код и сам вставляет вызовы free (условно) в то место, где владелец данных (переменная) выходит из скоупа (то есть гарантированно больше никто не может ссылаться на данные).
Контейнеры с подсчётами ссылок есть, но используются не часто.
Всю статью не читал, осилил только первый наброс про мутабельность, и вот это правильный комментарий.
Ссылки в расте надо интерпретировать именно так:
&mut T - уникальная ссылка. Из этого свойства как раз и вытекает возможность безопасной мутации объекта.
&T - шаренная ссылка. На этот объект может иметь доступ много кто, поэтому в общем случае изменять данные под ней нельзя. Но можно переложить ответственность за контроль корректного доступа (exactly one writer XOR multiple readers) в рантайм с помощью Mutex, RwLock или иных способов Interior Mutability.
К сожалению уже устоявшаяся классическая дискриминация по признаку наличия\отсутствия смартфона. Типа, если нету у тебя смартфона, то ты и не человек вовсе.
Это серверное оборудование, в любом сервере всегда имеется сильный воздушный поток вдоль всего корпуса. Все карты расширения предназначенные для серверов проектируются с учётом того, что хороший обдув будет обеспечен корпусными вентиляторами, соответственно ограничиваются только радиатором на чипах, но это не отменяет необходимость активного охлаждения.
Верно, actix-web не использует под капотом actix уже давно, добавление последнего к actix-web сейчас в основном имеет смысл только для реализации websocket'ов (да и то, это не обязательно, просто как один из вариантов, хотя пожалуй он самый удобный).
Сам actix как фрэймворк модели акторов для своих задач очень хорош, но в нём очень плохо с документацией, её по сути нет, только пару страниц с поверхностным описанием. Но естественно прочтение этих пары страниц не даёт полной картины как надо делать правильно, даже если есть багаж знаний об архитектуре модели акторов, например, из Erlang'а.
Ситуацию усугубляет то, что почти все, кто используют actix-web, именуют его просто actix'ом, и, как следствие, гугление по "actix" выдаёт нерелевантные результаты. По итогу, чтобы разобраться в actix, требуется изучать исходники самой библиотеки и искать какие-нибудь проекты на гитхабе использующие её. Это прямо боль.
По поводу db, хочется добавить, что есть очень хорошая ORM на основе sqlx: sea-orm, как альтернатива распиаренному diesel.
Зачем-то смешали в кучу actix и actix-web. Это совершенно разные продукты для решения разных задач. Статья даже не то, что слабая, а вообще вводит в заблуждение.
SSD использовались не для хранения плотов, а для создания. Сейчас уже не актуально, т.к. софт доработан и в основном плоты создаются в оперативной памяти.
Вывод всех доступных пакетов - какая-то бесполезная команда, если честно.
Есть `pacman -Ss [search_string]` , который является почти аналогом `apt search [search_string]`. Однако в pacman'е можно опустить аргумент поиска, в таком случае будет выведен весь список пакетов.
Потому что правила автовывода лайтаймов (lifetime elision) строго определены, и данный случай под эти правила не подходит.
Вот пример кода, где выставление одинакового лайфтайма (времени жизни, ВЖ) во всех местах в функции
foo_incorrectне пройдет проверку БЧ (borrow checker):Надо понимать, что БЧ выполняет проверку ВЖ для каждой функции отдельно, не заглядывая в тела других использующихся функций. То есть, в примере выше - неважно что будет написано в теле функций
foo_correct\foo_incorrect- проверка ВЖ для функцииmainот этого никак не изменится: учитываться будут только сигнатуры вызываемых функций.Если бы для каждой функции анализировались тела всех используемых функций, то время компиляции стремилось бы к бесконечности. Но что хуже - такое поведение вносило бы гораздо больше ошибок из-за неправильного вывода ВЖ. Даже стандартные правила вывода ВЖ иногда приводят к неверному результату, приходится вручную указывать (но это редко).
Компилятор не может знать что вы хотите написать, он может только проверить на корректность написанное.
Так вы в примере не используете
fooповторно вне замыкания. Речь именно об этом.А зачем тогда тащить C++, если в итоге будет C с классами? Так оно и так плюс-минус присутствует в коде ядра, местами. Если я ничего не путаю.
UPD: Ради контейнеров умных ссылок - ну не знаю, как будто бы и не стоит овчинка выделки.
Управление памятью реализовано через владение (ownership). Компилятор на этапе _компиляции_ анализирует код и сам вставляет вызовы free (условно) в то место, где владелец данных (переменная) выходит из скоупа (то есть гарантированно больше никто не может ссылаться на данные).
Контейнеры с подсчётами ссылок есть, но используются не часто.
Примеров, подтверждающих эти возгласы мы конечно же не увидим.
Автору надо ник поменять, а то его тёмное прошлое пестрит даже без резюме. /s
Всю статью не читал, осилил только первый наброс про мутабельность, и вот это правильный комментарий.
Ссылки в расте надо интерпретировать именно так:
&mut T- уникальная ссылка. Из этого свойства как раз и вытекает возможность безопасной мутации объекта.&T- шаренная ссылка. На этот объект может иметь доступ много кто, поэтому в общем случае изменять данные под ней нельзя. Но можно переложить ответственность за контроль корректного доступа (exactly one writer XOR multiple readers) в рантайм с помощьюMutex,RwLockили иных способов Interior Mutability.К сожалению уже устоявшаяся классическая дискриминация по признаку наличия\отсутствия смартфона. Типа, если нету у тебя смартфона, то ты и не человек вовсе.
Я вот понять не могу, откуда это утверждение взялось, что раст каждый релиз ломается?
Это серверное оборудование, в любом сервере всегда имеется сильный воздушный поток вдоль всего корпуса. Все карты расширения предназначенные для серверов проектируются с учётом того, что хороший обдув будет обеспечен корпусными вентиляторами, соответственно ограничиваются только радиатором на чипах, но это не отменяет необходимость активного охлаждения.
Вы так говорите, как будто действительно верите что Земля не плоская )
Я так понимаю, Бобрандреску это отсылка к А. Александреску.
Ну, с номера вашей бабушки позвонить уже не смогут, например.
Эта система режет только звонки с подменных номеров, а не те звонки про которые вы подумали.
Верно, actix-web не использует под капотом actix уже давно, добавление последнего к actix-web сейчас в основном имеет смысл только для реализации websocket'ов (да и то, это не обязательно, просто как один из вариантов, хотя пожалуй он самый удобный).
Сам actix как фрэймворк модели акторов для своих задач очень хорош, но в нём очень плохо с документацией, её по сути нет, только пару страниц с поверхностным описанием. Но естественно прочтение этих пары страниц не даёт полной картины как надо делать правильно, даже если есть багаж знаний об архитектуре модели акторов, например, из Erlang'а.
Ситуацию усугубляет то, что почти все, кто используют actix-web, именуют его просто actix'ом, и, как следствие, гугление по "actix" выдаёт нерелевантные результаты. По итогу, чтобы разобраться в actix, требуется изучать исходники самой библиотеки и искать какие-нибудь проекты на гитхабе использующие её. Это прямо боль.
По поводу db, хочется добавить, что есть очень хорошая ORM на основе sqlx: sea-orm, как альтернатива распиаренному diesel.
Почти сразу разобрались, мэйнтэйнер у actix-web есть.
Зачем-то смешали в кучу actix и actix-web. Это совершенно разные продукты для решения разных задач. Статья даже не то, что слабая, а вообще вводит в заблуждение.
SSD использовались не для хранения плотов, а для создания. Сейчас уже не актуально, т.к. софт доработан и в основном плоты создаются в оперативной памяти.
Вывод всех доступных пакетов - какая-то бесполезная команда, если честно.
Есть `pacman -Ss [search_string]` , который является почти аналогом `apt search [search_string]`. Однако в pacman'е можно опустить аргумент поиска, в таком случае будет выведен весь список пакетов.
Ну вообще, pacman это очень популярный мендежер, он по умолчанию поставляется в Arch и других дистрибутивах.
Существуют таблицы соответствия команд apt и pacman, которые легко гуглятся.