Продолжаем работать с 10.3.

КМБ.- Двойная жизнь.- Восстание мертвецов.- Ошибка в документации.- Ужасающие подробности из The Rustonomicon.- Архитектурные озарения.- Развязка.

• Предыдущая часть: Времена и функции
• Начало и содержание: Владение

КМБ по структурам

Простой вариант:

#[derive(Debug)] struct Point {     x: i32,     y: i32, }  #[derive(Debug)] struct Circle {     center: Point,     radius: i32, }  fn main(){     let p1 = Point{x:10, y:20};     println!("p: {:?}", p1);      let c = Circle{ center: Point{x: 1, y:2}, radius: 3,};     println!("c: {:?}", c); }

• #[derive(Debug)] обеспечивает генерацию кода для красивой печати через {:?}
• Все поля должны быть явно проинициализированы

Вариант с обобщенными типами:

#[derive(Debug)] struct Point<T> {     x: T,     y: T, }  #[derive(Debug)] struct Circle<T> {     center: Point<T>,     radius: T, }  fn main(){     let p_i32 = Point::<i32>{x:10, y:20};     println!("p_i32: {:?}", p_i32);      let p_str = Point::<&str>{x: "I'm x", y: "I'm y"};     println!("p_str: {:?}", p_str);      let c_f64 = Circle::<f64>{ center: Point{x: 1.1, y:2.2}, radius: 3.3,};     println!("c_f64: {:?}", c_f64); }

Структуры со ссылочными полями

До структур процесс засахаривания еще не дошел, поэтому необходимо явно аннотировать абсолютно все, что относится к временам жизни. Пример:

#[derive(Debug)] struct Point<'a, T> {     x: &'a T,     y: &'a T, }  #[derive(Debug)] struct Circle<'a, T> {     center: Point<'a, T>,     radius: &'a T, }  fn main(){     let p_i32 = Point::<i32>{x: &10, y: &20};     println!("p_i32: {:?}", p_i32);      let c_f64 = Circle::<f64>{ center: Point{x: &1.1, y: &2.2}, radius: &3.3,};     println!("c_f64: {:?}", c_f64); }

• &10 — занятно, Go так не может (cannot take the address of 10)
• Примеры неразрывно связаны с иррациональным ритуалом проставления 'a в параметрах структур и далее везде
• Как показано ранее, можно сделать Point<T>...Point::<&str>, что в итоге дает структуру с двумя ссылочными полями, явно времена нигде не указаны и ничего — пол не провалился
• В чем тут сила смысл, брат?

Может быть, смысл появится, если параметров времени жизни будет несколько?

Двойная жизнь

В текущей документации по Rust я не нашел внятного примера на этот счет, но зато он есть в одной из старых версий, 19.2 Advanced Lifetimes. В примере используются конструкции, которые мы еще «не проходили», так что я решил его немного переделать, заодно подправил «архитектуру» по своему вкусу.

Целью было заставить Rust выдавать ошибку компиляции, если используется только одно время жизни. Должен сказать, это удалось не сразу — обычно строгий, до садизма, компилятор в этот раз благодушно прощал мне попытки манипулировать временами. Интересно, что пример из старой версии теперь также прекрасно компилируется. Видимо, технические писатели помыкались, помыкались… да и не стали вообще рассказывать про это в новой версии.

Что ж, мы не привыкли отступать. Общий замысел примера таков — есть короткоживущий ('s) Parser и долгоживущий ('l) Context. Parser берет данные из Context и возвращает результат в рамках жизни Context (т.е. результат работы Parser тоже долгоживущий).

Context:

struct Context<'l> {     data: &'l str, }

• Здесь все живет долго ('l)

Parser:

struct Parser<'s, 'l: 's> {     ctx: &'s Context<'l>,     internal_data: &'s str, }

• struct Parser<'s, 'l: 's>: означает, что у структуры два параметра времени жизни, время жизни 'l включает в себя 's ('l outlives 's)
• ctx: &'s Context<'l> означает, что ctx является короткоживущей ссылкой, которая ссылается на экземпляр Context с долгоживущими ссылками внутри
• На всякий случай — вместо 's и 'l можно использовать другие имена, от этого ничего не изменится, т.е. это не какие-то магические спецслова

Метод Parser.parse():

impl<'s, 'l> Parser<'s, 'l> {     fn parse(&self) -> &'l str {         if self.ctx.data.len() > 1{             &self.ctx.data[1..]         } else {             self.ctx.data         }     } }

• Смысл метода — вернуть подстроку ctx.data начиная со второго байта, если этот второй байт есть

Все вместе:

#![allow(unused)]  struct Context<'l> {     data: &'l str, }  struct Parser<'s, 'l: 's> {     ctx: &'s Context<'l>,     internal_data: &'s str, }  impl<'s, 'l> Parser<'s, 'l> {     fn parse(&self) -> &'l str {         if self.ctx.data.len() > 0{             &self.ctx.data[1..]         } else {             self.ctx.data         }     } }  fn main(){     let working_ctx = Context{data: "0123456"};     let parsing_res: &str;     {         let dummy = &String::from("dummy");         let p = Parser{ctx: &working_ctx, internal_data: dummy};         parsing_res = p.parse();     }     println!("parsing_res: {}", parsing_res) }

Сломать это можно таким образом:

... impl<'a> Parser<'a, 'a> {     fn parse(&self) -> &'a str { ...

Тут как бы разработчик методов для Parser пренебрег указаниями проектировщика структуры и для реализации использовал только один параметр времени жизни. Вот этого компилятор уже простить не может, но сообщение при этом несколько странное:

26 |         let dummy = &String::from("dummy");    |                      ^^^^^^^^^^^^^^^^^^^^^ creates a temporary which is freed while still in use ... 29 |     }    |     - temporary value is freed at the end of this statement 30 |     println!("parsing_res: {}", parsing_res)    |                                 ----------- borrow later used here ...    = note: consider using a `let` binding to create a longer lived value

А вот и не угадал, dummy вообще не используется! Кроме того, должен признать, что совет про let мне непонятен. Конечно, приятно загнать в угол компилятор, но действует он в правильном направлении, и даже, возможно, по-своему прав.

Строка let p = Parser{ctx: &working_ctx, internal_data: dummy}; связывает с p два времени жизни, короткое от dummy и длинное от working_ctx, но по сигнатуре parse() теперь не понять, с каким из них связан результат, так что компилятор выбирает из двух зол времен наименьшее, т.е. dummy. C коротким временем жизни dummy связывать долгоживущий parsing_res, естественно, нельзя. Сообщение компилятора, конечно, оставляет желать лучшего, с lifetime такая проблема есть, этим даже ребята из Zürich озабочены.

Ладно, посмотрим, как можно дополнительно сломать уже сломанное, чтобы минус на минус дал плюс.

Первый вариант, инициализировать dummy таким образом:

... // let dummy = &String::from("dummy"); let dummy = "dummy"; ...

Все заработало, несмотря на то, что у нас все еще «закорочены» времена (impl<'a> Parser<'a, 'a>). В чем тут дело? Видать, компилятор использует не только сигнатуры, но и data-flow analysis.

Значение переменной dummy теперь связано со временем жизни 'static (возможно, компилятор вообще эту переменную «оптимизирует», в любом случае — ее значение не «тухнет») и переменная p, получается, связана либо со 'static, либо с working_ctx. Соответственно, возвращаемое p.parse() значение можно смело «поднимать» на уровень working_ctx, и код потенциально «сертифицируется» без всякой дополнительной разметки времен.

Тут, кстати, можно начать подозревать, что понятие «время жизни» относится не столько к ссылкам, сколько к значениям, на которые они указывают…

Второй вариант, убрать internal_data из Parser:

... struct Parser<'s, 'l: 's> {     ctx: &'s Context<'l>, } ...

Теперь p у нас инициализируется так: let p = Parser{ctx: &working_ctx};, т.е. она связана только с долгоживущим working_ctx и возвращаемое любыми методами Parser значения можно использовать там же, где и working_ctx.

Все? Нет, не все.

Структуры со ссылками в параметрах функций

Приготовьтесь, сейчас будет грустно.

Обратимся к документации по поводу неявного выведения времен жизни (lifetime elision):

Первое правило говорит, что каждый параметр являющийся ссылкой, получает свой собственный параметр времени жизни. Другими словами, функция с одним параметром получит один параметр времени жизни: fn foo<‘a>(x: &’a i32); функция с двумя аргументами получит два различных параметра времени жизни: fn foo<‘a, ‘b>(x: &’a i32, y: &’b i32) — и так далее.

Второе правило говорит, что если существует точно один входной параметр времени жизни, то его время жизни назначается всем выходным параметрам: fn foo<'a>(x: &'a i32) -> &'a i32.

Рассмотрим такой код:

... struct Circle<'a, T> {     center: Point<'a, T>,     radius: &'a T, }  fn get_radius<T>(c: &Circle<T>) -> &T {     c.radius }

Теперь следите за руками. Входной параметр один? Да. Ergo — будет один входной параметр времени жизни. Согласно второму правилу, время жизни этого параметра назначается всем выходным параметрам. Так почему же…:

15 | fn get_radius<T>(c: &Circle<T>) -> &T {    |                     ----------     ^ expected named lifetime parameter

А потому, что в документации написано неправильно. Может быть, это проблема перевода? Нет, это не проблема перевода, вот оригинал:

The first rule is that each parameter that is a reference gets its own lifetime parameter. In other words, a function with one parameter gets one lifetime parameter: fn foo<‘a>(x: &’a i32); a function with two parameters gets two separate lifetime parameters: fn foo<‘a, ‘b>(x: &’a i32, y: &’b i32); and so on.

The second rule is if there is exactly one input lifetime parameter, that lifetime is assigned to all output lifetime parameters: fn foo<‘a>(x: &’a i32) -> &’a i32.

Эта ошибочная формулировка пошла гулять по другим руководствам, немного мутируя по пути, см., например, тут: «…only one input parameter passes by reference…».

Где правда? Вестимо, в «старом учебнике» получше, тогда деревья были большие, и все такое — но все равно туманно, без примеров надлежащего качества. Относительно неплохо также изложено в страшном и ужасном The Rustonomicon, но уже несколько иными словами. Эти слова цитирует ув. PsyHaSTe тут, правда, при их интерпретации использует ошибочную формулировку:

… в случае статических функций время жизни всех аргументов полагаются равными…

Может быть это и опечатка, одну букву всего-то заменить… но ведь кто-то должен, наконец, сформулировать нормально на русском языке, да и примеров подходящих все равно нигде нет… Итак:

Правило 1. Неуказанные времена жизни во входных параметрах функции автоматически проставляются и полагаются разными.
Правило 2. Если во входных параметрах функции можно указать максимум одно время жизни, то оно используется для всех неуказанных времен в выходных параметрах.
Правило 3. Если во входных параметрах есть &self или &mut self, то время жизни этого параметра используется для всех неуказанных времен в выходных параметрах.

Теперь опять рассмотрим непонятный пример. Сколько времен жизни можно максимально указать во входящих параметрах? Два:

fn get_radius<'a, 'b, T>(c: &'a Circle<'b, T>) -> &T {     c.radius }

Собственно, как-то так они проставляются компилятором «для себя» по Правилу 1, соответственно, Правило 2 не работает. Как починить?

У нас два варианта — связать результат со временем жизни ссылки c или со временем жизни ссылок внутри того, на что указывает с.

Первый вариант:

fn get_radius<'a, 'b, T>(c: &'a Circle<'b, T>) -> &'a T {

или:

fn get_radius<'c, T>(c: &'c Circle<T>) -> &'c T {

Второй вариант:

fn get_radius<'a, 'b, T>(c: &'a Circle<'b, T>) -> &'b T {

или

fn get_radius<'circle, T>(c: &Circle<'circle, T>) -> &'circle T {

И последний пример::

... fn get_radius<T>(c: Circle<T>) -> &T {     c.radius }

Во входящих параметрах нет ни ссылок ни времен, почему работает? А потому, что можно указать только одно время жизни, соответственно, срабатывает Правило 2:

fn get_radius<'a, T>(c: Circle<'a, T>) -> &T {     c.radius }

Размышления про архитектуру приложения

Сложность написания и, что немаловажно, сложность чтения кода с большим количеством параметров времени жизни в структурах с увеличением числа этих самых параметров растет экспоненциально (или даже круче!), так что, КМК, лучше избегать сложных случаев.

• Структуры должны быть простыми, с одним параметром времени жизни (S — SOLID)
• «Агрегировать» структуры следует на уровне функций/методов
• Есть даже такое мнение: You’re not allowed to use references in structs until you think Rust is easy…Use Box or Arc to store things in structs «by reference» (про Box и Arc будет в следующих частях)

В свете сказанного Parser можно переписать так:

struct Context<'a> {     data: &'a str, }  struct Parser<'a>  {     internal_data: &'a str, }  impl<'s, 'l: 's> Parser<'s> {     fn parse(&self, ctx: &'l Context) -> &'l str { ...

Или, используя anonymous lifetime, так (но пропадает соотношение времен):

... impl Parser<'_> {     fn parse<'l>(&self, ctx: &'l Context) -> &'l str { ...

• Мы больше не храним ссылку на Context внутри Parser, а передаем прямо в метод parse()
• В реализации методов для Parser мы указываем компилятору, что возвращаемое значение parse() связано параметром ctx
• В принципе, соотносить времена не требуется, достаточно того, что они разные. Parser живет дольше Context? — Ну ок, почему нет. Главное, не использовать результат в более «широкой» области, чем Context, но тут-то компилятор за всем проследит!

Заключение

Конспект получился длиннее лекции, но это ничего — зато теперь можно смело идти получать «зачет»по 10.3.

Провидению препоручаю вас, дети мои, и заклинаю: остерегайтесь использовать ссылки в структурах, особенно в сложных структурах. Это, конечно, была шутка. Тем не менее — praemonitus praemunitus, forewarned is forearmed и так далее.

Stay tuned.

PS: Далее: Работа с кучей