@@ -176,16 +176,18 @@ <h1 class="menu-title">The Rust Programming Language 日本語版</h1>
176
176
-->
177
177
< h2 id ="ライフタイムで参照を検証する "> < a class ="header " href ="#ライフタイムで参照を検証する "> ライフタイムで参照を検証する</ a > </ h2 >
178
178
<!--
179
- One detail we didn’t discuss in the “References and Borrowing” section in
180
- Chapter 4 is that every reference in Rust has a *lifetime*, which is the scope
181
- for which that reference is valid. Most of the time, lifetimes are implicit and
182
- inferred, just like most of the time, types are inferred. We must annotate types
183
- when multiple types are possible. In a similar way, we must annotate lifetimes
184
- when the lifetimes of references could be related in a few different ways. Rust
185
- requires us to annotate the relationships using generic lifetime parameters to
186
- ensure the actual references used at runtime will definitely be valid.
187
- -->
188
- < p > 第4章の「参照と借用」節で議論しなかった詳細の一つに、Rustにおいて参照は全てライフタイムを保持するということがあります。
179
+ One detail we didn’t discuss in the [“References and
180
+ Borrowing”][references-and-borrowing] section in Chapter 4 is
181
+ that every reference in Rust has a *lifetime*, which is the scope for which
182
+ that reference is valid. Most of the time, lifetimes are implicit and
183
+ inferred, just like most of the time, types are inferred. We must annotate
184
+ types when multiple types are possible. In a similar way, we must annotate
185
+ lifetimes when the lifetimes of references could be related in a few different
186
+ ways. Rust requires us to annotate the relationships using generic lifetime
187
+ parameters to ensure the actual references used at runtime will definitely be
188
+ valid.
189
+ -->
190
+ < p > 第4章の< a href ="ch04-02-references-and-borrowing.html#%E5%8F%82%E7%85%A7%E3%81%A8%E5%80%9F%E7%94%A8 "> 「参照と借用」</ a > 節で議論しなかった詳細の一つに、Rustにおいて参照は全てライフタイムを保持するということがあります。
189
191
ライフタイムとは、その参照が有効になるスコープのことです。多くの場合、型が推論されるように、
190
192
大体の場合、ライフタイムも暗黙的に推論されます。複数の型の可能性があるときには、型を注釈しなければなりません。
191
193
同様に、参照のライフタイムがいくつか異なる方法で関係することがある場合には注釈しなければなりません。
@@ -198,13 +200,11 @@ <h2 id="ライフタイムで参照を検証する"><a class="header" href="#ラ
198
200
languages, arguably making lifetimes Rust’s most distinctive feature. Although
199
201
we won’t cover lifetimes in their entirety in this chapter, we’ll discuss
200
202
common ways you might encounter lifetime syntax so you can become familiar with
201
- the concepts. See the “Advanced Lifetimes” section in Chapter 19 for more
202
- detailed information.
203
+ the concepts.
203
204
-->
204
205
< p > ライフタイムの概念は、他のプログラミング言語の道具とはどこか異なり、間違いなく、
205
206
Rustで一番際立った機能になっています。この章では、ライフタイムの全体を解説することはしませんが、
206
- ライフタイム記法が必要となる最も一般的な場合について議論しますので、ライフタイムの概念について馴染むことができるでしょう。
207
- もっと詳しく知るには、第19章の「高度なライフタイム」節を参照してください。</ p >
207
+ ライフタイム記法が必要となる最も一般的な場合について議論しますので、ライフタイムの概念について馴染むことができるでしょう。</ p >
208
208
<!--
209
209
### Preventing Dangling References with Lifetimes
210
210
-->
@@ -235,9 +235,9 @@ <h3 id="ライフタイムでダングリング参照を回避する"><a class="
235
235
-->
236
236
< p > < span class ="caption "> リスト10-17: 値がスコープを抜けてしまった参照を使用しようとする</ span > </ p >
237
237
<!--
238
- > Note: The example in Listing 10-17, 10-18, and 10-24 declare variables
238
+ > Note: The examples in Listings 10-17, 10-18, and 10-24 declare variables
239
239
> without giving them an initial value, so the variable name exists in the
240
- > outer scope. At first glance, this might appear to be in conflict with Rust' s
240
+ > outer scope. At first glance, this might appear to be in conflict with Rust’ s
241
241
> having no null values. However, if we try to use a variable before giving it
242
242
> a value, we’ll get a compile-time error, which shows that Rust indeed does
243
243
> not allow null values.
@@ -296,7 +296,7 @@ <h3 id="借用精査機"><a class="header" href="#借用精査機">借用精査
296
296
<!--
297
297
The Rust compiler has a *borrow checker* that compares scopes to determine
298
298
whether all borrows are valid. Listing 10-18 shows the same code as Listing
299
- 10-17 but with annotations showing the lifetimes of the variables:
299
+ 10-17 but with annotations showing the lifetimes of the variables.
300
300
-->
301
301
< p > Rustコンパイラには、スコープを比較して全ての借用が有効であるかを決定する< em > 借用チェッカー</ em > があります。
302
302
リスト10-18は、リスト10-17と同じコードを示していますが、変数のライフタイムを表示する注釈が付いています:</ p >
@@ -400,20 +400,15 @@ <h3 id="関数のジェネリックなライフタイム"><a class="header" href
400
400
<!--
401
401
Note that we want the function to take string slices, which are references,
402
402
because we don’t want the `longest` function to take ownership of its
403
- parameters. We want to allow the function to accept slices of a `String` (the
404
- type stored in the variable `string1`) as well as string literals (which is
405
- what variable `string2` contains).
403
+ parameters. Refer to the [“String Slices as
404
+ Parameters”][string-slices-as-parameters] section in Chapter 4
405
+ for more discussion about why the parameters we use in Listing 10-20 are the
406
+ ones we want.
406
407
-->
407
408
< p > 関数に取ってほしい引数が文字列スライス、つまり参照であることに注意してください。
408
409
何故なら、< code > longest</ code > 関数に引数の所有権を奪ってほしくないからです。
409
- この関数に< code > String</ code > のスライス(変数< code > string1</ code > に格納されている型)と文字列リテラル(変数< code > string2</ code > が含むもの)を受け取らせたいのです。</ p >
410
- <!--
411
- Refer to the “String Slices as Parameters” section in Chapter 4 for more
412
- discussion about why the parameters we use in Listing 10-20 are the ones we
413
- want.
414
- -->
415
- < p > リスト10-20で使用している引数が、我々が必要としているものである理由についてもっと詳しい議論は、
416
- 第4章の「引数としての文字列スライス」節をご参照ください。</ p >
410
+ リスト10-20で使用している引数が、我々が必要としているものである理由についてもっと詳しい議論は、
411
+ 第4章の< a href ="ch04-03-slices.html#%E5%BC%95%E6%95%B0%E3%81%A8%E3%81%97%E3%81%A6%E3%81%AE%E6%96%87%E5%AD%97%E5%88%97%E3%82%B9%E3%83%A9%E3%82%A4%E3%82%B9 "> 「引数としての文字列スライス」</ a > 節をご参照ください。</ p >
417
412
<!--
418
413
If we try to implement the `longest` function as shown in Listing 10-21, it
419
414
won’t compile.
@@ -586,19 +581,23 @@ <h3 id="関数シグニチャにおけるライフタイム注釈"><a class="hea
586
581
takes two parameters, both of which are string slices that live at least as
587
582
long as lifetime `'a`. The function signature also tells Rust that the string
588
583
slice returned from the function will live at least as long as lifetime `'a`.
589
- These constraints are what we want Rust to enforce. Remember, when we specify
590
- the lifetime parameters in this function signature, we’re not changing the
591
- lifetimes of any values passed in or returned. Rather, we’re specifying that
592
- the borrow checker should reject any values that don’t adhere to these
593
- constraints. Note that the `longest` function doesn’t need to know exactly how
594
- long `x` and `y` will live, only that some scope can be substituted for `'a`
595
- that will satisfy this signature.
584
+ In practice, it means that the lifetime of the reference returned by the
585
+ `longest` function is the same as the smaller of the lifetimes of the
586
+ references passed in. These constraints are what we want Rust to enforce.
587
+ Remember, when we specify the lifetime parameters in this function signature,
588
+ we’re not changing the lifetimes of any values passed in or returned. Rather,
589
+ we’re specifying that the borrow checker should reject any values that don’t
590
+ adhere to these constraints. Note that the `longest` function doesn’t need to
591
+ know exactly how long `x` and `y` will live, only that some scope can be
592
+ substituted for `'a` that will satisfy this signature.
596
593
-->
597
594
< p > これで関数シグニチャは、何らかのライフタイム< code > 'a</ code > に対して、関数は2つの引数を取り、
598
595
どちらも少なくともライフタイム< code > 'a</ code > と同じだけ生きる文字列スライスであるとコンパイラに教えるようになりました。
599
596
また、この関数シグニチャは、関数から返る文字列スライスも少なくともライフタイム< code > 'a</ code > と同じだけ生きると、
600
- コンパイラに教えています。これらの制約は、まさに私たちがコンパイラに保証してほしかったものです。
601
- この関数シグニチャでライフタイム引数を指定する時、渡されたり、返したりした、いかなる値のライフタイムも変更していないことを思い出してください。
597
+ コンパイラに教えています。
598
+ 実際には、< code > longest</ code > 関数が返す参照のライフタイムは、渡された参照のうち、小さい方のライフタイムと同じであるという事です。
599
+ これらの制約は、まさに私たちがコンパイラに保証してほしかったものです。</ p >
600
+ < p > この関数シグニチャでライフタイム引数を指定する時、渡されたり、返したりした、いかなる値のライフタイムも変更していないことを思い出してください。
602
601
むしろ、借用チェッカーは、これらの制約を守らない値全てを拒否するべきと指定しています。
603
602
< code > longest</ code > 関数は、< code > x</ code > と< code > y</ code > の正確な生存期間を知っている必要はなく、
604
603
このシグニチャを満たすようなスコープを< code > 'a</ code > に代入できることを知っているだけであることに注意してください。</ p >
@@ -973,7 +972,7 @@ <h3 id="ライフタイム省略"><a class="header" href="#ライフタイム省
973
972
were entering the same lifetime annotations over and over in particular
974
973
situations. These situations were predictable and followed a few deterministic
975
974
patterns. The developers programmed these patterns into the compiler’s code so
976
- the borrow checker could infer the lifetimes in these situations and wouldn' t
975
+ the borrow checker could infer the lifetimes in these situations and wouldn’ t
977
976
need explicit annotations.
978
977
-->
979
978
< p > 多くのRustコードを書いた後、Rustチームは、Rustプログラマが特定の場面では、
@@ -1019,12 +1018,13 @@ <h3 id="ライフタイム省略"><a class="header" href="#ライフタイム省
1019
1018
there aren’t explicit annotations. The first rule applies to input lifetimes,
1020
1019
and the second and third rules apply to output lifetimes. If the compiler gets
1021
1020
to the end of the three rules and there are still references for which it can’t
1022
- figure out lifetimes, the compiler will stop with an error.
1021
+ figure out lifetimes, the compiler will stop with an error. These rules apply
1022
+ to `fn` definitions as well as `impl` blocks.
1023
1023
-->
1024
1024
< p > コンパイラは3つの規則を活用し、明示的な注釈がない時に、参照がどんなライフタイムになるかを計算します。
1025
1025
最初の規則は入力ライフタイムに適用され、2番目と3番目の規則は出力ライフタイムに適用されます。
1026
1026
コンパイラが3つの規則の最後まで到達し、それでもライフタイムを割り出せない参照があったら、
1027
- コンパイラはエラーで停止します。</ p >
1027
+ コンパイラはエラーで停止します。これらのルールは < code > fn </ code > の定義にも < code > impl </ code > ブロックにも適用されます。 </ p >
1028
1028
<!--
1029
1029
The first rule is that each parameter that is a reference gets its own lifetime
1030
1030
parameter. In other words, a function with one parameter gets one lifetime
@@ -1171,7 +1171,7 @@ <h3 id="メソッド定義におけるライフタイム注釈"><a class="header
1171
1171
< span class ="boring "> }
1172
1172
</ span > </ code > </ pre > </ pre >
1173
1173
<!--
1174
- The lifetime parameter declaration after `impl` and use after the type name
1174
+ The lifetime parameter declaration after `impl` and its use after the type name
1175
1175
are required, but we’re not required to annotate the lifetime of the reference
1176
1176
to `self` because of the first elision rule.
1177
1177
-->
@@ -1212,11 +1212,11 @@ <h3 id="メソッド定義におけるライフタイム注釈"><a class="header
1212
1212
-->
1213
1213
< h3 id ="静的ライフタイム "> < a class ="header " href ="#静的ライフタイム "> 静的ライフタイム</ a > </ h3 >
1214
1214
<!--
1215
- One special lifetime we need to discuss is `'static`, which denotes the entire
1216
- duration of the program. All string literals have the `'static` lifetime, which
1217
- we can annotate as follows:
1215
+ One special lifetime we need to discuss is `'static`, which means that this
1216
+ reference *can* live for the entire duration of the program. All string
1217
+ literals have the `'static` lifetime, which we can annotate as follows:
1218
1218
-->
1219
- < p > 議論する必要のある1種の特殊なライフタイムが、< code > 'static</ code > であり、これはプログラム全体の期間を示します 。
1219
+ < p > 議論する必要のある1種の特殊なライフタイムが、< code > 'static</ code > であり、これは、この参照がプログラムの全期間生存 < em > できる </ em > 事を意味します 。
1220
1220
文字列リテラルは全て< code > 'static</ code > ライフタイムになり、次のように注釈できます:</ p >
1221
1221
< pre > < pre class ="playground "> < code class ="language-rust ">
1222
1222
< span class ="boring "> #![allow(unused)]
@@ -1226,7 +1226,7 @@ <h3 id="静的ライフタイム"><a class="header" href="#静的ライフタイ
1226
1226
< span class ="boring "> }
1227
1227
</ span > </ code > </ pre > </ pre >
1228
1228
<!--
1229
- The text of this string is stored directly in the binary of your program, which
1229
+ The text of this string is stored directly in the program’s binary , which
1230
1230
is always available. Therefore, the lifetime of all string literals is
1231
1231
`'static`.
1232
1232
-->
@@ -1312,13 +1312,14 @@ <h2 id="まとめ"><a class="header" href="#まとめ">まとめ</a></h2>
1312
1312
<!--
1313
1313
Believe it or not, there is much more to learn on the topics we discussed in
1314
1314
this chapter: Chapter 17 discusses trait objects, which are another way to use
1315
- traits. Chapter 19 covers more complex scenarios involving lifetime annotations
1316
- as well as some advanced type system features. But next, you’ll learn how to
1317
- write tests in Rust so you can make sure your code is working the way it should.
1315
+ traits. There are also more complex scenarios involving lifetime annotations
1316
+ that you will only need in very advanced scenarios; for those, you should read
1317
+ the [Rust Reference][reference]. But next, you’ll learn how to write tests in
1318
+ Rust so you can make sure your code is working the way it should.
1318
1319
-->
1319
1320
< p > 信じるかどうかは自由ですが、この章で議論した話題にはもっともっと学ぶべきことがあります:
1320
1321
第17章ではトレイトオブジェクトを議論します。これはトレイトを使用する別の手段です。
1321
- 第19章では、ライフタイム注釈が関わるもっと複雑な筋書きと何か高度な型システムの機能を講義します。
1322
+ 非常に高度な筋書きの場合でのみ必要になる、ライフタイム注釈が関わる、もっと複雑な筋書きもあります。 それらについては、 < a href =" https://doc.rust-lang.org/reference/ " > Rust Reference </ a > をお読みください。
1322
1323
ですが次は、コードがあるべき通りに動いていることを確かめられるように、Rustでテストを書く方法を学びます。</ p >
1323
1324
1324
1325
</ main >
0 commit comments