Skip to content

Commit

Permalink
Translate ch10-03-lifetime-syntax.md via GitLocalize
Browse files Browse the repository at this point in the history
  • Loading branch information
dluschan authored and gitlocalize-app[bot] committed Oct 12, 2023
1 parent d025a21 commit 919e1c5
Showing 1 changed file with 5 additions and 5 deletions.
10 changes: 5 additions & 5 deletions rustbook-ru/src/ch10-03-lifetime-syntax.md
Original file line number Diff line number Diff line change
Expand Up @@ -2,9 +2,9 @@

Сроки (времена) жизни - ещё один вид обобщений, с которыми мы уже встречались. Если раньше мы использовали обобщения, чтобы убедиться, что тип обладает нужным нам поведением, теперь мы будем использовать сроки жизни для того, чтобы быть уверенными, что ссылки действительны как минимум столько времени в процессе исполнения программы, сколько нам требуется.

One detail we didn’t discuss in the [“References and Borrowing”](ch04-02-references-and-borrowing.html#references-and-borrowing)<!-- ignore --> section in Chapter 4 is that every reference in Rust has a *lifetime*, which is the scope for which that reference is valid. Most of the time, lifetimes are implicit and inferred, just like most of the time, types are inferred. We must only annotate types when multiple types are possible. In a similar way, we must annotate lifetimes when the lifetimes of references could be related in a few different ways. Rust requires us to annotate the relationships using generic lifetime parameters to ensure the actual references used at runtime will definitely be valid.
В разделе ["Ссылки и заимствование"](ch04-02-references-and-borrowing.html#references-and-borrowing) главы 4, мы кое о чём умолчали: у каждой ссылки в Rust есть своё <em>время жизни</em> — область кода, на протяжении которого данная ссылка действительна (valid). В большинстве случаев сроки жизни выводятся неявно — так же, как у типов (нам требуется явно объявлять типы лишь в тех случаях, когда при автоматическом выведении типа возможны варианты). Точно так же мы должны явно объявлять сроки жизни тех ссылок, для которых времена жизни могут быть определены компилятором по-разному. Rust требует от нас объявлять взаимосвязи посредством обобщённых параметров сроков жизни, чтобы убедиться в том, что во время исполнения все действующие ссылки будут корректными.

Annotating lifetimes is not a concept most other programming languages have, so this is going to feel unfamiliar. Although we won’t cover lifetimes in their entirety in this chapter, we’ll discuss common ways you might encounter lifetime syntax so you can get comfortable with the concept.
Аннотирование времени жизни — это концепция, отсутствующая в большинстве других языков программирования, так что она может показаться незнакомой. Хотя в этой главе мы не будем рассматривать времена жизни во всех деталях, тем не менее, мы обсудим основные ситуации, в которых вы можете столкнуться с синтаксисом времени жизни, что позволит вам получше ознакомиться с этой концепцией.

### Времена жизни предотвращают появление "повисших" ссылок

Expand All @@ -18,7 +18,7 @@ Annotating lifetimes is not a concept most other programming languages have, so

> Примечание: примеры в листингах 10-16, 10-17 и 10-23 объявляют переменные без указания их начального значения, поэтому имя переменной существует во внешней области видимости. На первый взгляд может показаться, что это противоречит отсутствию в Rust нулевых (null) значений. Однако, если мы попытаемся использовать переменную, прежде чем присвоить ей значение, мы получим ошибку компиляции, которая показывает, что Rust действительно не разрешает нулевые (null) значения.
The outer scope declares a variable named `r` with no initial value, and the inner scope declares a variable named `x` with the initial value of 5. Inside the inner scope, we attempt to set the value of `r` as a reference to `x`. Then the inner scope ends, and we attempt to print the value in `r`. This code won’t compile because what the value `r` is referring to has gone out of scope before we try to use it. Here is the error message:
Внешняя область видимости объявляет переменную с именем `r` без начального значения, а внутренняя область объявляет переменную с именем `x` с начальным значением `5`. Во внутренней области мы пытаемся установить значение `r` как ссылку на `x`. Затем внутренняя область видимости заканчивается и мы пытаемся напечатать значение из `r`. Этот код не будет скомпилирован, потому что значение на которое ссылается <code>r</code> исчезает из области видимости, прежде чем мы попробуем использовать его. Вот сообщение об ошибке:

```console
{{#include ../listings/ch10-generic-types-traits-and-lifetimes/listing-10-16/output.txt}}
Expand Down Expand Up @@ -152,9 +152,9 @@ The outer scope declares a variable named `r` with no initial value, and the inn
{{#include ../listings/ch10-generic-types-traits-and-lifetimes/listing-10-23/output.txt}}
```

Эта ошибка говорит о том, что если мы хотим использовать `result` в `println!`, переменная `string2` должна бы быть действительной до конца внешней области видимости. Rust знает об этом, потому что мы аннотировали параметры функции и её возвращаемое значение одинаковым временем жизни `'a`.
Эта ошибка говорит о том, что если мы хотим использовать `result` в инструкции `println!`, переменная `string2` должна бы быть действительной до конца внешней области видимости. Rust знает об этом, потому что мы аннотировали параметры функции и её возвращаемое значение одинаковым временем жизни `'a`.

Будучи людьми, мы можем посмотреть на этот код и увидеть, что `string1` длиннее, чем `string2` и, следовательно, `result` будет содержать ссылку на `string1`. Поскольку `string1` ещё не вышла из области видимости, ссылка на `string1` будет все ещё действительной в выражении `println!`. Однако компилятор не видит, что ссылка в этом случае валидна. Мы сказали Rust, что время жизни ссылки, возвращаемой из функции `longest`, равняется меньшему из времён жизни переданных в неё ссылок. Таким образом, анализатор заимствований запрещает код в листинге 10-23, как возможно имеющий недействительную ссылку.
Будучи людьми, мы можем посмотреть на этот код и увидеть, что `string1` длиннее, чем `string2` и, следовательно, `result` будет содержать ссылку на `string1`. Поскольку `string1` ещё не вышла из области видимости, ссылка на `string1` будет все ещё действительной в инструкции `println!`. Однако компилятор не видит, что ссылка в этом случае валидна. Мы сказали Rust, что время жизни ссылки, возвращаемой из функции `longest`, равняется меньшему из времён жизни переданных в неё ссылок. Таким образом, анализатор заимствований запрещает код в листинге 10-23, как возможно имеющий недействительную ссылку.

Попробуйте провести больше экспериментов с различными значениями и временами жизни ссылок, передаваемых в функцию `longest`, а также с тем, как используется возвращаемое значение Перед компиляцией делайте предположения о том, пройдёт ли ваш код анализ заимствований, а затем проверяйте, насколько вы были правы.

Expand Down

0 comments on commit 919e1c5

Please sign in to comment.