Merge pull request #140 from nojima/master-ja

ch10-03 の訳を一部修正する

Author: tatsuya6502

src/ch10-03-lifetime-syntax.md

@@ -35,9 +35,9 @@ detailed information.
 -->
 
 ライフタイムの概念は、他のプログラミング言語の道具とはどこか異なり、間違いなく、
-Rustで一番際立った機能になっています。この章では、ライフタイムの全てを講義しないものの、
-ライフタイム記法と遭遇する可能性のある一般的な手段を議論するので、その概念に馴染めます。
-もっと詳しく知るには、第19章の「高度なライフタイム」節を参照されたし。
+Rustで一番際立った機能になっています。この章では、ライフタイムの全体を解説することはしませんが、
+ライフタイム記法が必要となる最も一般的な場合について議論しますので、ライフタイムの概念について馴染むことができるでしょう。
+もっと詳しく知るには、第19章の「高度なライフタイム」節を参照してください。
 
 <!--
 ### Preventing Dangling References with Lifetimes
@@ -391,9 +391,9 @@ the lifetimes of multiple references to each other without affecting the
 lifetimes.
 -->
 
-ライフタイム注釈は、いかなる参照の生存期間も変えることはありません。シグニチャがジェネリックな型引数を指定していると、
-関数があらゆる型を受け入れるのと全く同様に、ジェネリックなライフタイム引数を指定することで関数は、
-あらゆるライフタイムの参照を受け入れるのです。ライフタイム注釈は、ライフタイムに影響することなく、
+ライフタイム注釈は、いかなる参照の生存期間も変えることはありません。シグニチャにジェネリックな型引数を指定された
+関数が、あらゆる型を受け取ることができるのと同様に、ジェネリックなライフタイム引数を指定された関数は、
+あらゆるライフタイムの参照を受け取ることができます。ライフタイム注釈は、ライフタイムに影響することなく、
 複数の参照のライフタイムのお互いの関係を記述します。
 
 <!--
@@ -441,7 +441,7 @@ lifetime.
 お互いにどう関係するかをコンパイラに指示することを意図しているからです。例えば、
 ライフタイム`'a`付きの`i32`への参照となる引数`first`のある関数があるとしましょう。
 この関数にはさらに、`'a`のライフタイム付きの`i32`への別の参照となる`second`という別の引数もあります。
-ライフタイム注釈は、`first`と`second`の参照がどちらもジェネリックなライフタイムと同じだけ生きることを示唆します。
+ライフタイム注釈は、`first`と`second`の参照がどちらもこのジェネリックなライフタイムと同じだけ生きることを示唆します。
 
 <!--
 ### Lifetime Annotations in Function Signatures
@@ -459,10 +459,10 @@ We’ll name the lifetime `'a` and then add it to each reference, as shown in
 Listing 10-22.
 -->
 
-さて、`longest`関数の文脈でライフタイム注釈を調査しましょう。ジェネリックな型引数同様、
-関数名と引数リストの間、山カッコの中にジェネリックなライフタイム引数を宣言する必要があります。
-このシグニチャで表現したい制約は、引数の全参照と戻り値が同じライフタイムになることです。
-ライフタイムを`'a`と名付け、それから各参照に追記します。リスト10-22に示したように。
+さて、`longest`関数を例にライフタイム注釈を詳しく見ていきましょう。ジェネリックな型引数同様、
+関数名と引数リストの間の山カッコの中にジェネリックなライフタイム引数を宣言します。
+このシグニチャで表現したい制約は、引数の全ての参照と戻り値が同じライフタイムを持つことです。
+リスト10-22に示すように、ライフタイムを`'a`と名付け、それを各参照に付与します。
 
 <!--
 <span class="filename">Filename: src/main.rs</span>
@@ -486,7 +486,7 @@ specifying that all the references in the signature must have the same lifetime
 `'a`</span>
 -->
 
-<span class="caption">リスト10-22: シグニチャの全参照が同じライフタイム`'a`になると指定した`longest`関数の定義</span>
+<span class="caption">リスト10-22: シグニチャの全参照が同じライフタイム`'a`を持つと指定した`longest`関数の定義</span>
 
 <!--
 This code should compile and produce the result we want when we use it with the
@@ -512,11 +512,11 @@ that will satisfy this signature.
 これで関数シグニチャは、何らかのライフタイム`'a`に対して、関数は2つの引数を取り、
 どちらも少なくともライフタイム`'a`と同じだけ生きる文字列スライスであるとコンパイラに教えるようになりました。
 また、この関数シグニチャは、関数から返る文字列スライスも少なくともライフタイム`'a`と同じだけ生きると、
-コンパイラに教えています。これらの制約は、コンパイラに強制してほしいものです。
+コンパイラに教えています。これらの制約は、まさに私たちがコンパイラに保証してほしかったものです。
 この関数シグニチャでライフタイム引数を指定する時、渡されたり、返したりした、いかなる値のライフタイムも変更していないことを思い出してください。
 むしろ、借用チェッカーは、これらの制約を守らない値全てを拒否するべきと指定しています。
-`longest`関数は、正確に`x`と`y`の生存期間を知る必要はなく、何かのスコープが`'a`に代替され、
-このシグニチャを満足することだけ知っている必要があることに注意してください。
+`longest`関数は、`x`と`y`の正確な生存期間を知っている必要はなく、
+このシグニチャを満たすようなスコープを`'a`に代入できることを知っているだけであることに注意してください。
 
 <!--
 When annotating lifetimes in functions, the annotations go in the function
@@ -528,10 +528,10 @@ might be different each time the function is called. This is why we need to
 annotate the lifetimes manually.
 -->
 
-関数でライフタイムを注釈する際、注釈は関数シグニチャに<ruby>嵌<rp>(</rp><rt>はま</rt><rp>)</rp></ruby>り、
-関数本体には嵌りません。コンパイラは、なんの助けもなく、関数内のコードを解析できます。しかしながら、
-関数に、関数外からの参照や、関数外への参照がある場合、コンパイラは引数や戻り値のライフタイムをそれだけで解決することはほとんど不可能になります。
-ライフタイムは、関数が呼び出される度に異なる可能性があります。このために、手動でライフタイムを注釈する必要があるのです。
+関数にライフタイムを注釈するときは、注釈は関数の本体ではなくシグニチャに付与します。
+コンパイラは注釈がなくとも関数内のコードを解析できます。しかしながら、
+関数に関数外からの参照や関数外への参照がある場合、コンパイラが引数や戻り値のライフタイムを自力で解決することはほとんど不可能になります。
+そのライフタイムは、関数が呼び出される度に異なる可能性があります。このために、手動でライフタイムを注釈する必要があるのです。
 
 <!--
 When we pass concrete references to `longest`, the concrete lifetime that is
@@ -543,7 +543,7 @@ the returned reference will also be valid for the length of the smaller of the
 lifetimes of `x` and `y`.
 -->
 
-具体的な参照を`longest`に渡すと、`'a`を代替する具体的なライフタイムは、`y`のスコープと被さる`x`のスコープの一部になります。
+具体的な参照を`longest`に渡すと、`'a`に代入される具体的なライフタイムは、`x`のスコープの一部であって`y`のスコープと重なる部分となります。
 言い換えると、ジェネリックなライフタイム`'a`は、`x`と`y`のライフタイムのうち、小さい方に等しい具体的なライフタイムになるのです。
 返却される参照を同じライフタイム引数`'a`で注釈したので、返却される参照も`x`か`y`のライフタイムの小さい方と同じだけ有効になるでしょう。
 
@@ -553,7 +553,7 @@ passing in references that have different concrete lifetimes. Listing 10-23 is
 a straightforward example.
 -->
 
-ライフタイム注釈が異なる具体的なライフタイムになる参照を渡すことで`longest`関数を制限する方法を見ましょう。
+ライフタイム注釈が異なる具体的なライフタイムを持つ参照を渡すことで`longest`関数を制限する方法を見ましょう。
 リスト10-23は、率直な例です。
 
 <!--
@@ -588,7 +588,7 @@ fn main() {
 references to `String` values that have different concrete lifetimes</span>
 -->
 
-<span class="caption">リスト10-23: 異なる具体的なライフタイムの`String`値への参照で`longest`関数を使用する</span>
+<span class="caption">リスト10-23: 異なる具体的なライフタイムを持つ`String`値への参照で`longest`関数を使用する</span>
 
 <!--
 In this example, `string1` is valid until the end of the outer scope, `string2`
@@ -669,7 +669,7 @@ this because we annotated the lifetimes of the function parameters and return
 values using the same lifetime parameter `'a`.
 -->
 
-このエラーは、`result`が`println!`文に対して有効になるために、`string2`が外側のスコープの終わりまで有効である必要があることを示しています。
+このエラーは、`result`が`println!`文に対して有効であるためには、`string2`が外側のスコープの終わりまで有効である必要があることを示しています。
 関数引数と戻り値のライフタイムを同じライフタイム引数`'a`で注釈したので、コンパイラはこのことを知っています。
 
 <!--
@@ -683,11 +683,11 @@ the lifetimes of the references passed in. Therefore, the borrow checker
 disallows the code in Listing 10-24 as possibly having an invalid reference.
 -->
 
-人間からしたら、このコードを見て`string1`は`string2`よりも長いことが確認でき、
-故に`result`は`string1`への参照を含んでいます。まだ`string1`はスコープを抜けていないので、
-それでも`string1`への参照は`println!`にとって有効でしょう。ですが、コンパイラはこの場合、
+人間からしたら、`string1`は`string2`よりも長く、それ故に`result`が`string1`への参照を含んでいることは
+コードから明らかです。まだ`string1`はスコープを抜けていないので、
+`string1`への参照は`println!`にとって有効でしょう。ですが、コンパイラはこの場合、
 参照が有効であると見なせません。`longest`関数から返ってくる参照のライフタイムは、
-渡した参照のうちの小さい方と同じだとコンパイラに指示しました。それ故に、
+渡した参照のうちの小さい方と同じだとコンパイラに指示しました。したがって、
 借用チェッカーは、リスト10-24のコードを無効な参照がある可能性があるとして許可しないのです。
 
 <!--
@@ -714,7 +714,7 @@ string slice, we wouldn’t need to specify a lifetime on the `y` parameter. The
 following code will compile:
 -->
 
-ライフタイム引数を指定する必要のある手段は、関数が行っていることによります。例えば、
+何にライフタイム引数を指定する必要があるかは、関数が行っていることに依存します。例えば、
 `longest`関数の実装を最長の文字列スライスではなく、常に最初の引数を返すように変更したら、
 `y`引数に対してライフタイムを指定する必要はなくなるでしょう。以下のコードはコンパイルできます:
 
@@ -821,9 +821,10 @@ enough information to allow memory-safe operations and disallow operations that
 would create dangling pointers or otherwise violate memory safety.
 -->
 
-究極的にライフタイム記法は、関数のいろんな引数と戻り値のライフタイムを接続することに関するのです。
-一旦、繋がりができたら、メモリ安全な処理を許可するのに十分な情報がコンパイラにはあり、
-ダングリングポインタを生成するであろう処理を不認可し、さもなくばメモリ安全性を侵害するのです。
+究極的にライフタイム記法は、関数のいろんな引数と戻り値のライフタイムを接続することに関するものです。
+一旦それらが繋がれば、メモリ安全な処理を許可し、
+ダングリングポインタを生成したりメモリ安全性を侵害したりする処理を禁止するのに
+十分な情報をコンパイラは得たことになります。
 
 <!--
 ### Lifetime Annotations in Struct Definitions