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

Возврат либо
NewsArticle либо
Tweet не допускается из-за ограничений того, как реализован синтаксис impl Trait в компиляторе. Мы рассмотрим, как написать функцию с таким поведением в разделе "Использование объектов типажей, которые разрешены для значений или разных типов"
Главы 17.
Использование ограничений типажа для условной реализации
методов
Используя ограничение типажа с блоком impl
, который использует параметры обобщённого типа, можно реализовать методы условно, для тех типов, которые реализуют указанный типаж. Например, тип
Pair
в листинге 10-16 всегда реализует функцию new для возврата нового экземпляра
Pair
(вспомните раздел
“Определение методов”
Главы 5 где
Self является псевдонимом типа для типа блока impl
, который в данном случае является
Pair
). Но в следующем блоке impl тип
Pair
реализует метод cmp_display только если его внутренний тип
T
реализует типаж
PartialOrd
(позволяющий сравнивать) и типаж
Display
(позволяющий выводить на печать).
Файл: src/lib.rs
Листинг 10-15: Условная реализация методов у обобщённых типов в зависимости от ограничений типажа
Мы также можем условно реализовать типаж для любого типа, который реализует другой типаж. Реализации типажа для любого типа, который удовлетворяет ограничениям типажа, называются общими реализациями и широко используются в стандартной библиотеке Rust. Например, стандартная библиотека реализует типаж
ToString для use std::fmt::Display; struct
Pair
{ x: T, y: T,
} impl
Pair { fn new
(x: T, y: T) ->
Self
{
Self
{ x, y }
}
} impl
PartialOrd
> Pair { fn cmp_display
(&
self
) { if self
.x >= self
.y { println!
(
"The largest member is x = {}"
, self
.x);
} else
{ println!
(
"The largest member is y = {}"
, self
.y);
}
}
}

любого типа, который реализует типаж
Display
. Блок impl в стандартной библиотеке выглядит примерно так:
Поскольку стандартная библиотека имеет эту общую реализацию, то можно вызвать метод to_string определённый типажом
ToString для любого типа, который реализует типаж
Display
. Например, мы можем превратить целые числа в их соответствующие
String значения, потому что целые числа реализуют типаж
Display
:
Общие реализации приведены в документации к типажу в разделе "Implementors".
Типажи и ограничения типажей позволяют писать код, который использует параметры обобщённого типа для уменьшения дублирования кода, а также указывая компилятору,
что мы хотим обобщённый тип, чтобы иметь определённое поведение. Затем компилятор может использовать информацию про ограничения типажа, чтобы проверить, что все конкретные типы, используемые с нашим кодом, обеспечивают правильное поведение. В динамически типизированных языках мы получили бы ошибку во время выполнения, если бы вызвали метод для типа, который не реализует тип определяемый методом. Но Rust перемещает эти ошибки на время компиляции, поэтому мы вынуждены исправить проблемы, прежде чем наш код начнёт работать. Кроме того,
мы не должны писать код, который проверяет своё поведение во время выполнения,
потому что это уже проверено во время компиляции. Это повышает производительность без необходимости отказываться от гибкости обобщённых типов.
impl

ToString for
T {
// --snip--
} let s =
3
.to_string();

Валидация ссылок при помощи времён жизни
Сроки (времена) жизни - ещё один вид обобщений, с которыми мы уже встречались. Если раньше мы использовали обобщения, чтобы убедиться, что тип обладает нужным нам поведением, теперь мы будем использовать сроки жизни для того, чтобы быть уверенными, что ссылки действительны как минимум столько времени в процессе исполнения программы, сколько нам требуется.
В разделе "Ссылки и заимствование"
главы 4, мы кое о чем умолчали: у каждой ссылки в
Rust есть своё время жизни - область кода, на протяжении которого данная ссылка действительна (valid). В большинстве случаев сроки жизни выводятся неявно - так же, как у типов (нам требуется явно объявлять типы лишь в тех случаях, когда при автоматическом выведении типа возможны варианты). Точно так же мы должны явно объявлять сроки жизни тех ссылок, для которых времена жизни могут быть определены компилятором по-разному. Rust требует от нас объявлять взаимосвязи посредством обобщённых параметров сроков жизни - чтобы убедиться в том, что во время исполнения все действующие ссылки будут корректными.
Аннотирование времени жизни — это концепция, отсутствующая в большинстве других языков программирования, так что она может показаться незнакомой. Хотя в этой главе мы не будем рассматривать времена жизни во всех деталях, тем не менее, мы обсудим основные ситуации, в которых вы можете столкнуться с синтаксисом времени жизни, что позволит вам получше ознакомиться с этой концепцией.
Времена жизни предотвращают появление "повисших" ссылок
Основное предназначение сроков жизни — предотвращать появление так называемых
"повисших ссылок" (dangling references), из-за которых программа обращается не к тем данным, к которым она собиралась обратиться. Рассмотрим программу из листинга 10-
16, имеющую внешнюю и внутреннюю области видимости.
Листинг 10-16: Попытка использования ссылки, значение которой вышло из области видимости
Примечание: примеры в листингах 10-16, 10-17 и 10-23 объявляют переменные без указания их начального значения, поэтому имя переменной существует во fn main
() { let r;
{ let x =
5
; r = &x;
} println!
(
"r: {}"
, r);
}

внешней области видимости. На первый взгляд может показаться, что это противоречит отсутствию в Rust нулевых (null) значений. Однако, если мы попытаемся использовать переменную, прежде чем присвоить ей значение, мы получим ошибку компиляции, которая показывает, что Rust действительно не разрешает нулевые (null) значения.
Внешняя область видимости объявляет переменную с именем r
без начального значения, а внутренняя область объявляет переменную с именем x
с начальным значением
5
. Во внутренней области мы пытаемся установить значение r
как ссылку на x
. Затем внутренняя область видимости заканчивается и мы пытаемся напечатать значение из r
. Этот код не будет скомпилирован, потому что значение на которое ссылается r
исчезает из области видимости, прежде чем мы попробуем использовать его. Вот сообщение об ошибке:
Переменная x
«не живёт достаточно долго». Причина в том, что x
выйдет из области видимости, когда эта внутренняя область закончится в строке 7. Но r
все ещё является действительной во внешней области видимости; поскольку её охват больше, мы говорим, что она «живёт дольше». Если бы Rust позволил такому коду работать, то переменная r
смогла бы ссылаться на память, которая уже была освобождена (в тот момент, когда x
вышла из внутренней области видимости), и всё что мы попытались бы сделать с r
работало бы неправильно. Как же Rust определяет, что этот код некорректен? Он использует для этого анализатор заимствований (borrow checker).

Пример 10-17: Аннотация времён жизни переменных
r
и
x
, с помощью идентификаторов времени жизни
'a
и
'b
, соответственно
Здесь мы описали время жизни для r
с помощью 'a и время жизни x
с помощью 'b
Как видите, время жизни 'b внутреннего блока гораздо меньше, чем время жизни 'a внешнего блока. Во время компиляции Rust сравнивает продолжительность двух времён жизни и видит, что r
имеет время жизни 'a
, но ссылается на память со временем жизни 'b
. Программа отклоняется, потому что 'b короче, чем 'a
: объект ссылки не живёт так же долго, как сама ссылка.
Листинг 10-18 исправляет код, чтобы в нём не было повисшей ссылки, и компилируется без ошибок.
Листинг 10-18: Ссылка корректна, так как данные имеют более продолжительное время жизни, чем ссылка
на эти данные
Здесь переменная x
имеет время жизни 'b
, которое больше, чем время жизни 'a
. Это означает, что переменная r
может ссылаться на переменную x
потому что Rust знает,
что ссылка в переменной r
будет всегда действительной до тех пор, пока переменная x
является валидной.
После того, как мы на примерах рассмотрели времена жизни ссылок и обсудили как Rust их анализирует, давайте поговорим об обобщённых временах жизни входных параметров и возвращаемых значений функций.
Обобщённые времена жизни в функциях
fn main
() { let r;
// ---------+-- 'a
// |
{
// |
let x =
5
;
// -+-- 'b |
r = &x;
// | |
}
// -+ |
// |
println!
(
"r: {}"
, r);
// |
}
// ---------+
fn main
() { let x =
5
;
// ----------+-- 'b
// |
let r = &x;
// --+-- 'a |
// | |
println!
(
"r: {}"
, r);
// | |
// --+ |
}
// ----------+

Напишем функцию, которая возвращает более длинный из двух срезов строки. Эта функция принимает два среза строки и возвращает один срез строки. После того как мы реализовали функцию longest
, код в листинге 10-19 должен вывести
The longest string is abcd
Файл: src/main.rs
Листинг 10-19: Функция
main
вызывает функцию
longest
для поиска наибольшего из двух срезов строки
Обратите внимание, что мы хотим чтобы функция принимала строковые срезы, которые являются ссылками, а не строки, потому что мы не хотим, чтобы функция longest забирала во владение свои параметры. Обратитесь к разделу "Строковые срезы как параметры"
Главы 4 для более подробного обсуждения того, почему параметры используемые в листинге 10-19 выбраны именно таким образом.
Если мы попробуем реализовать функцию longest так, как это показано в листинге 10-
20, программа не скомпилируется:
Файл: src/main.rs
Листинг 10-20: Реализация функции
longest
, которая возвращает наибольший срез строки, но пока не
компилируется
Вместо этого мы получим следующую ошибку, говорящую о временах жизни:
fn main
() { let string1 =
String
::from(
"abcd"
); let string2 =
"xyz"
; let result = longest(string1.as_str(), string2); println!
(
"The longest string is {}"
, result);
} fn longest
(x: &
str
, y: &
str
) -> &
str
{ if x.len() > y.len() { x
} else
{ y
}
}

Текст ошибки показывает, что возвращаемому типу нужен обобщённый параметр времени жизни, потому что Rust не может определить, относится ли возвращаемая ссылка к x
или к y
. На самом деле, мы тоже не знаем, потому что блок if в теле функции возвращает ссылку на x
, а блок else возвращает ссылку на y
!
Когда мы определяем эту функцию, мы не знаем конкретных значений, которые будут в неё передаваться. Поэтому мы не знаем какая из ветвей оператора if или else будет выполнена. Мы также не знаем конкретных времён жизни ссылок, которые будут переданы в функцию, поэтому мы не можем посмотреть на их области видимости, как мы делали в примерах 10-17 и 10-18, чтобы определить, будет ли возвращаемая нами ссылка корректной во всех случаях. Анализатор заимствований также не может этого определить, потому что он не знает как времена жизни переменных x
и y
соотносятся с временем жизни возвращаемого значения. Чтобы исправить эту ошибку, мы добавим обобщённый параметр времени жизни, который определит отношения между ссылками таким образом, чтобы анализатор заимствований мог провести свой анализ.
Синтаксис аннотации времени жизни
Аннотации времени жизни не меняют срок, как долго живёт та или иная ссылка. Они скорее описывают, как соотносятся между собой времена жизни нескольких ссылок, не влияя на само время жизни. Точно так же, как функции могут принимать любой тип,
когда в сигнатуре указан параметр обобщённого типа, функции могут принимать ссылки с любым временем жизни, указанным с помощью параметра обобщённого времени жизни.
Аннотации времени жизни имеют немного необычный синтаксис: имена параметров времени жизни должны начинаться с апострофа (
'
), пишутся маленькими буквами, и обычно очень короткие, как и имена обобщённых типов. Большинство людей использует имя 'a в качестве первой аннотации времени жизни. Аннотации
$
cargo run
Compiling chapter10 v0.1.0 (file:///projects/chapter10) error[E0106]: missing lifetime specifier
-->
src/main.rs:9:33
|
9 | fn longest(x: &str, y: &str) -> &str {
| ---- ---- ^ expected named lifetime parameter
|
= help: this function's return type contains a borrowed value, but the signature does not say whether it is borrowed from `x` or `y` help: consider introducing a named lifetime parameter
|
9 | fn longest<'a>(x: &'a str, y: &'a str) -> &'a str {
| ++++ ++ ++ ++
For more information about this error, try `rustc --explain E0106`. error: could not compile `chapter10` due to previous error

параметров времени жизни следуют после символа
&
и отделяются пробелом от названия ссылочного типа.
Приведём несколько примеров: у нас есть ссылка на i32
без указания времени жизни,
ссылка на i32
, с временем жизни имеющим имя 'a и изменяемая ссылка на i32
,
которая также имеет время жизни 'a
Одна аннотация времени жизни сама по себе не имеет большого значения, поскольку аннотации предназначены для того, чтобы проинформировать Rust о том, как времена жизни нескольких ссылок соотносятся между собой. Давайте рассмотрим, как аннотации времени жизни связаны друг с другом в контексте функции longest
Аннотации времени жизни в сигнатурах функций
Чтобы использовать аннотации времени жизни в сигнатурах функций, нам нужно объявить параметры обобщённого времени жизни внутри угловых скобок между именем функции и списком параметров, как мы это делали с параметрами обобщённого типа .
Мы хотим, чтобы сигнатура отражала следующее ограничение: возвращаемая ссылка будет действительна до тех пор, пока валидны оба параметра. Это связь между временами жизни параметров и возвращаемого значения. Мы назовём это время жизни 'a
, а затем добавим его к каждой ссылке, как показано в листинге 10-21.
Файл: src/main.rs
Листинг 10-21: В определении функции
longest
указано, что все ссылки должны иметь одинаковое время
жизни, обозначенное как
'a
Этот код должен компилироваться и давать желаемый результат, когда мы вызовем его в функции main листинга 10-19.
Сигнатура функции теперь сообщает Rust, что для некоторого времени жизни 'a функция принимает два параметра, оба из которых являются срезами строк, которые живут не меньше, чем время жизни 'a
. Сигнатура функции также сообщает Rust, что срез строки, возвращаемый функцией, будет жить как минимум столько, сколько длится
&
i32
// ссылка
&
'a i32
// ссылка с явным временем жизни
&
'a mut i32
// изменяемая ссылка с явным временем жизни fn longest
<
'a
>(x: &
'a str
, y: &
'a str
) -> &
'a str
{ if x.len() > y.len() { x
} else
{ y
}
}

время жизни 'a
. На практике это означает, что время жизни ссылки, возвращаемой функцией longest
, равно меньшему времени жизни передаваемых в неё ссылок. Мы хотим, чтобы Rust использовал именно такие отношения при анализе этого кода.
Помните, когда мы указываем параметры времени жизни в этой сигнатуре функции, мы не меняем время жизни каких-либо переданных или возвращённых значений. Скорее,
мы указываем, что анализатор заимствований должен отклонять любые значения,
которые не соответствуют этим ограничениям. Обратите внимание, что самой функции longest не нужно точно знать, как долго будут жить x
и y
, достаточно того, что некоторая область может быть заменена на 'a
, которая будет удовлетворять этой сигнатуре.
При аннотировании времён жизни функций, аннотации помещаются в сигнатуру функции, а не в тело функции. Аннотации времени жизни становятся частью контракта функции, как и типы в сигнатуре. Наличие сигнатур функций, содержащих контракт времени жизни, означает, что анализ который выполняет компилятор Rust, может быть проще. Если есть проблема с тем, как функция аннотируется или как она вызывается,
ошибки компилятора могут указать на часть нашего кода и ограничения более точно.
Если бы вместо этого компилятор Rust сделал больше предположений о том, какие отношения времён жизни мы хотели получить, компилятор смог бы указать только на использование нашего кода за много шагов от источника проблемы.
Когда мы передаём конкретные ссылки в функцию longest
, конкретным временем жизни, которое будет заменено на 'a
, является часть области видимости x
, которая пересекается с областью видимости y
. Другими словами, обобщённое время жизни 'a получит конкретное время жизни, равное меньшему из времён жизни x
и y
. Так как мы аннотировали возвращаемую ссылку тем же параметром времени жизни 'a
, то возвращённая ссылка также будет действительна на протяжении меньшего из времён жизни x
и y
Давайте посмотрим, как аннотации времени жизни ограничивают функцию longest путём передачи в неё ссылок, которые имеют разные конкретные времена жизни.
Листинг 10-22 является очевидным примером.
Файл: src/main.rs
Листинг 10-22: Использование функции
longest
со ссылками на значения типа
String
, имеющими разное
время жизни
fn main
() { let string1 =
String
::from(
"long string is long"
);
{ let string2 =
String
::from(
"xyz"
); let result = longest(string1.as_str(), string2.as_str()); println!
(
"The longest string is {}"
, result);
}
}