Материал: Язык программирования Rust

В этом примере переменная string1
действительна до конца внешней области, string2
действует до конца внутренней области видимости и result ссылается на что-то, что является действительным до конца внутренней области видимости. Запустите этот код, и вы увидите что анализатор заимствований разрешает такой код; он скомпилирует и напечатает
The longest string is long string is long
Теперь, давайте попробуем пример, который показывает, что время жизни ссылки result должно быть меньшим временем жизни одного из двух аргументов. Мы переместим объявление переменной result за пределы внутренней области видимости, но оставим присвоение значения переменной result в области видимости string2
. Затем мы переместим println!
, который использует result за пределы внутренней области видимости, после того как внутренняя область видимости закончилась. Код в листинге 10-23 не скомпилируется.
Файл: src/main.rs
Листинг 10-23: Попытка использования
result
, после того как
string2
вышла из области видимости
При попытке скомпилировать этот код, мы получим такую ошибку:
Эта ошибка говорит о том, что если мы хотим использовать result в println!
,
переменная string2
должна бы быть действительной до конца внешней области видимости. Rust знает об этом, потому что мы аннотировали параметры функции и её
возвращаемое значение одинаковым временем жизни 'a fn main
() { let string1 =
String
::from(
"long string is long"
); let result;
{ let string2 =
String
::from(
"xyz"
); result = longest(string1.as_str(), string2.as_str());
} println!
(
"The longest string is {}"
, result);
}
$
cargo run
Compiling chapter10 v0.1.0 (file:///projects/chapter10) error[E0597]: `string2` does not live long enough
-->
src/main.rs:6:44
|
6 | result = longest(string1.as_str(), string2.as_str());
| ^^^^^^^^^^^^^^^^ borrowed value does not live long enough
7 | }
| - `string2` dropped here while still borrowed
8 | println!("The longest string is {}", result);
| ------ borrow later used here
For more information about this error, try `rustc --explain E0597`. error: could not compile `chapter10` due to previous error

Будучи людьми, мы можем посмотреть на этот код и увидеть, что string1
живёт дольше,
чем string2
и, следовательно, result будет содержать ссылку на string1
. Поскольку string1
ещё не вышла из области видимости, ссылка на string1
будет все ещё
действительной в выражении println!
. Однако компилятор не видит, что ссылка в этом случае валидна. Мы сказали Rust, что время жизни ссылки, возвращаемой из функции longest
, равняется меньшему из времён жизни переданных в неё ссылок. Таким образом, анализатор заимствований запрещает код в листинге 10-23, как возможно имеющий недействительную ссылку.
Попробуйте провести больше экспериментов с различными значениями и временами жизни ссылок, передаваемых в функцию longest
, а также с тем, как используется возвращаемое значение Перед компиляцией делайте предположения о том, пройдёт ли ваш код анализ заимствований, а затем проверяйте, насколько вы были правы.
Мышление в терминах времён жизни
В зависимости от того, что делает ваша функция, следует использовать разные способы указания параметров времени жизни. Например, если мы изменим реализацию функции longest таким образом, чтобы она всегда возвращала свой первый аргумент вместо самого длинного среза строки, то время жизни для параметра y
можно совсем не указывать. Этот код скомпилируется:
Файл: src/main.rs
Мы указали параметр времени жизни 'a для параметра x
и возвращаемого значения,
но не для параметра y
, поскольку время жизни параметра y
никак не соотносится с временем жизни параметра x
или возвращаемого значения.
При возврате ссылки из функции, параметр времени жизни для возвращаемого типа должен соответствовать параметру времени жизни одного из аргументов. Если возвращаемая ссылка не ссылается на один из параметров, она должна ссылаться на значение, созданное внутри функции. Однако, это приведёт к недействительной ссылке,
поскольку значение, на которое она ссылается, выйдет из области видимости в конце функции. Посмотрите на попытку реализации функции longest
, которая не скомпилируется:
Файл: src/main.rs fn longest
<
'a
>(x: &
'a str
, y: &
str
) -> &
'a str
{ x
} fn longest
<
'a
>(x: &
str
, y: &
str
) -> &
'a str
{ let result =
String
::from(
"really long string"
); result.as_str()
}

Здесь, несмотря на то, что мы указали параметр времени жизни 'a для возвращаемого типа, реализация не будет скомпилирована, потому что время жизни возвращаемого значения никак не связано с временем жизни параметров. Получаем сообщение об ошибке:
Проблема заключается в том, что result выходит за область видимости и очищается в конце функции longest
. Мы также пытаемся вернуть ссылку на result из функции. Мы не можем указать параметры времени жизни, которые могли бы изменить недействительную ссылку, а Rust не позволит нам создать недействительную ссылку. В
этом случае лучшим решением будет вернуть владеющий тип данных, а не ссылку: в этом случае вызывающая функция будет нести ответственность за очистку полученного ею значения.
В конечном итоге, синтаксис времён жизни реализует связывание времён жизни различных аргументов и возвращаемых значений функций. Описывая времена жизни,
мы даём Rust достаточно информации, чтобы разрешить безопасные операции с памятью и запретить операции, которые могли бы создать недействительные ссылки или иным способом нарушить безопасность памяти.
Определение времён жизни при объявлении структур
До сих пор мы объявляли структуры, которые всегда содержали владеющие типы данных. Структуры могут содержать и ссылки, но при этом необходимо добавить аннотацию времени жизни для каждой ссылки в определении структуры. Листинг 10-24
описывает структуру
ImportantExcerpt
, содержащую срез строки:
Файл: src/main.rs
$
cargo run
Compiling chapter10 v0.1.0 (file:///projects/chapter10) error[E0515]: cannot return reference to local variable `result`
-->
src/main.rs:11:5
|
11 | result.as_str()
| ^^^^^^^^^^^^^^^ returns a reference to data owned by the current function
For more information about this error, try `rustc --explain E0515`. error: could not compile `chapter10` due to previous error

Листинг 10-25. Структура, содержащая ссылку, требует аннотации времени жизни
У структуры имеется одно поле part
, хранящее срез строки, который сам по себе является ссылкой. Как и в случае с обобщёнными типами данных, мы объявляем имя обобщённого параметра времени жизни в внутри угловых скобок после имени структуры, чтобы иметь возможность использовать его внутри определения структуры.
Данная аннотация означает, что экземпляр
ImportantExcerpt не может пережить ссылку,
которую он содержит в своём поле part
Функция main здесь создаёт экземпляр структуры
ImportantExcerpt
, который содержит ссылку на первое предложение типа
String принадлежащее переменной novel
Данные в novel существуют до создания экземпляра
ImportantExcerpt
. Кроме того, novel не выходит из области видимости до тех пор, пока
ImportantExcerpt не выйдет за область видимости, поэтому ссылка в внутри экземпляра
ImportantExcerpt является действительной.

Листинг 10-25: Функция, которую мы определили в листинге 4-9 компилируется без аннотаций времени
жизни, несмотря на то, что входной и возвращаемый тип параметров являются ссылками
Причина, по которой этот код компилируется — историческая. В ранних (до-1.0) версиях
Rust этот код не скомпилировался бы, поскольку каждой ссылке нужно было явно назначать время жизни. В те времена, сигнатура функции была бы написана примерно так:
После написания большого количества кода на Rust разработчики языка обнаружили,
что в определённых ситуациях программисты описывают одни и те же аннотации времён жизни снова и снова. Эти ситуации были предсказуемы и следовали нескольким детерминированным шаблонным моделям. Команда Rust решила запрограммировать эти шаблоны в код компилятора Rust, чтобы анализатор заимствований мог вывести времена жизни в таких ситуациях без необходимости явного указания аннотаций программистами.
Мы упоминаем этот фрагмент истории Rust, потому что возможно, что в будущем появится больше шаблонов для автоматического выведения времён жизни, которые будут добавлены в компилятор. Таким образом, в будущем может понадобится ещё
меньшее количество аннотаций.
Шаблоны, запрограммированные в анализаторе ссылок языка Rust, называются
правилами неявного выведения времени жизни. Это не правила, которым должны следовать программисты; а набор частных случаев, которые рассмотрит компилятор, и,
если ваш код попадает в эти случаи, вам не нужно будет указывать время жизни явно.
Правила выведения не предоставляют полного заключения. Если Rust детерминировано применяет правила, но некоторая неясность относительно времён жизни ссылок все ещё
остаётся, компилятор не будет догадываться, какими должны быть времена жизни оставшихся ссылок. В этом случае, вместо угадывания компилятор выдаст ошибку,
которую вы можете устранить, добавив аннотации времени жизни.
Времена жизни параметров функции или метода называются временем жизни ввода, а времена жизни возвращаемых значений называются временем жизни вывода.
Компилятор использует три правила, чтобы выяснить времена жизни ссылок при отсутствии явных аннотаций. Первое правило относится ко времени жизни ввода, второе и третье правила применяются ко временам жизни вывода. Если компилятор доходит до конца проверки трёх правил и всё ещё есть ссылки, для которых он не может выяснить время жизни, компилятор остановится с ошибкой. Эти правила применяются к объявлениям fn
, а также к блокам impl{/code1.
Первое правило заключается в том, что каждый параметр являющийся ссылкой,
получает свой собственный параметр времени жизни. Другими словами, функция с одним параметром получит один параметр времени жизни: fn foo<'a>(x: &'a i32)
;
fn first_word
<
'a
>(s: &
'a str
) -> &
'a str
{

функция с двумя аргументами получит два отдельных параметра времени жизни: fn foo<'a, 'b>(x: &'a i32, y: &'b i32)
, и так далее.
Второе правило говорит, что если есть ровно один входной параметр времени жизни, то его время жизни назначается всем выходным параметрам: fn foo<'a>(x: &'a i32) ->
&'a i32
Третье правило о том, что если есть множество входных параметров времени жизни, но один из них является ссылкой
&self или
&mut self
, так как эта функция является методом, то время жизни self назначается временем жизни всем выходным параметрам. Это третье правило делает методы намного приятнее для чтения и записи,
потому что требуется меньше символов.
Представим, что мы компилятор и применим эти правила, чтобы вывести времена жизни ссылок в сигнатуре функции first_word листинга 10-25. Сигнатура этой функции начинается без объявления времён жизни ссылок:
Теперь мы (в качестве компилятора) применим первое правило, утверждающее, что каждый параметр функции получает своё собственное время жизни. Как обычно,
назовём его 'a и теперь сигнатура выглядит так:
Далее применяем второе правило, поскольку в функции указан только один входной параметр времени жизни. Второе правило гласит, что время жизни единственного входного параметра назначается выходным параметрам, поэтому сигнатура теперь преобразуется таким образом:
Теперь все ссылки в этой функции имеют параметры времени жизни и компилятор может продолжить свой анализ без необходимости просить у программиста указать аннотации времён жизни в сигнатуре этой функции.
Давайте рассмотрим ещё один пример: на этот раз функцию longest
, в которой не было параметров времени жизни, когда мы начали с ней работать в листинге 10-20:
Применим первое правило: каждому параметру назначается собственное время жизни.
На этот раз у функции есть два параметра, поэтому есть два времени жизни:
fn first_word
(s: &
str
) -> &
str
{ fn first_word
<
'a
>(s: &
'a str
) -> &
str
{ fn first_word
<
'a
>(s: &
'a str
) -> &
'a str
{ fn longest
(x: &
str
, y: &
str
) -> &
str
{ fn longest
<
'a
,
'b
>(x: &
'a str
, y: &
'b str
) -> &
str
{

Можно заметить, что второе правило здесь не применимо, так как в сигнатуре указано больше одного входного параметра времени жизни. Третье правило также не применимо, так как longest
— функция, а не метод, следовательно, в ней нет параметра self
. Итак, мы прошли все три правила, но так и не смогли вычислить время жизни выходного параметра. Поэтому мы и получили ошибку при попытке скомпилировать код листинга 10-20: компилятор работал по правилам неявного выведения времён жизни, но не мог выяснить все времена жизни ссылок в сигнатуре.
Так как третье правило применяется только к методам, далее мы рассмотрим времена жизни в этом контексте, чтобы понять, почему нам часто не требуется аннотировать времена жизни в сигнатурах методов.
Аннотация времён жизни в определении методов
Когда мы реализуем методы для структур с временами жизни, мы используем тот же синтаксис, который применялся для аннотаций обобщённых типов данных на листинге
10-11. Место, где мы объявляем и используем времена жизни, зависит от того, с чем они связаны — с полями структуры, либо с аргументами методов и возвращаемыми значениями.
Имена параметров времени жизни для полей структур всегда описываются после ключевого слова impl и затем используются после имени структуры, поскольку эти времена жизни являются частью типа структуры.
В сигнатурах методов внутри блока impl ссылки могут быть привязаны ко времени жизни ссылок в полях структуры, либо могут быть независимыми. Вдобавок, правила неявного выведения времён жизни часто делают так, что аннотации переменных времён жизни являются необязательными в сигнатурах методов. Рассмотрим несколько примеров, использующих структуру с названием
ImportantExcerpt
, которую мы определили в листинге 10-24.
Сначала, воспользуемся методом level
, чей единственный параметр является ссылкой на self
, а возвращаемое значение i32
, не является ссылкой ни на что:
Объявление параметра времени жизни после impl и его использование после имени типа является обязательным, но нам не нужно аннотировать время жизни ссылки на self
, благодаря первому правилу неявного выведения времён жизни.
Вот пример, где применяется третье правило неявного выведения времён жизни:
impl
<
'a
> ImportantExcerpt<
'a
> { fn level
(&
self
) -> i32
{
3
}
}

В этом методе имеется два входных параметра, поэтому Rust применит первое правило и назначит обоим параметрам
&self и announcement собственные времена жизни. Далее,
поскольку один из параметров является
&self
, то возвращаемое значение получает время жизни переменой
&self и все времена жизни теперь выведены.
Статическое время жизни
Одно особенное время жизни, которое мы должны обсудить, называется 'static
. Оно означает, что данная ссылка может жить всю продолжительность работы программы.
Все строковые литералы по умолчанию имеют время жизни 'static
, но мы можем указать его явным образом:
Содержание этой строки сохраняется внутри бинарного файл программы и всегда доступно для использования. Следовательно, время жизни всех строковых литералов равно 'static
Сообщения компилятора об ошибках в качестве решения проблемы могут предлагать вам использовать время жизни 'static
. Но прежде чем указывать 'static как время жизни для ссылки, подумайте, на самом ли деле данная ссылка будет доступна во всё
время работы программы. В большинстве случаев, сообщения об ошибках,
предлагающие использовать время жизни 'static появляются при попытках создания недействительных ссылок или несовпадения имеющихся времён жизни. В таких случаях,
решение заключается в исправлении таких проблем, а не в указании статического времени жизни 'static
Обобщённые типы параметров, ограничения типажей
и времена жизни вместе
Давайте кратко рассмотрим синтаксис задания параметров обобщённых типов,
ограничений типажа и времён жизни совместно в одной функции:
impl
<
'a
> ImportantExcerpt<
'a
> { fn announce_and_return_part
(&
self
, announcement: &
str
) -> &
str
{ println!
(
"Attention please: {}"
, announcement); self
.part
}
} let s: &
'static str
=
"I have a static lifetime."
;

Это функция longest из листинга 10-21, которая возвращает наибольший из двух срезов строки. Но теперь у неё есть дополнительный параметр с именем ann обобщённого типа
T
, который может быть представлен любым типом, реализующим типаж
Display
,
как указано в предложении where
. Этот дополнительный параметр будет напечатан с использованием
{}
, поэтому ограничение типажа
Display необходимо. Поскольку время жизни является обобщённым типом, то объявления параметра времени жизни 'a и параметра обобщённого типа
T
помещаются в один список внутри угловых скобок после имени функции.
Итоги
В этой главе мы рассмотрели много всего! Теперь вы знакомы с параметрами обобщённого типа, типажами и ограничениями типажа, обобщёнными параметрами времени жизни, вы готовы писать код без повторений, который будет работать во множестве различных ситуаций. Параметры обобщённого типа позволяют использовать код для различных типов данных. Типажи и ограничения типажа помогают убедиться,
что, хотя типы и обобщённые, они будут вести себя, как этого требует ваш код. Вы изучили, как использовать аннотации времени жизни чтобы убедиться, что этот универсальный код не будет генерировать никаких повисших ссылок. И весь этот анализ происходит в момент компиляции и не влияет на производительность программы во время работы!
Верите или нет, но в рамках этой темы всё есть ещё чему поучиться: в Главе 17
обсуждаются типажи-объекты, которые являются ещё одним способом использования типажей. Существуют также более сложные сценарии с аннотациями времени жизни,
которые вам понадобятся только в очень сложных случаях; для этого вам следует прочитать
Rust Reference
. Далее вы узнаете, как писать тесты на Rust, чтобы убедиться,
что ваш код работает так, как задумано.
use std::fmt::Display; fn longest_with_an_announcement
<
'a
, T>( x: &
'a str
, y: &
'a str
, ann: T,
) -> &
'a str where
T: Display,
{ println!
(
"Announcement! {}"
, ann); if x.len() > y.len() { x
} else
{ y
}
}