3838<!-- is _done at compile time_. You do not pay any run-time cost for any of these -->
3939<!-- features. -->
4040Rustは安全性とスピートに焦点を合わせます。
41- Rustはそれらの目標をたくさんの「ゼロコスト抽象化」を通じて成し遂げます。それは、Rustでは抽象化を機能させるためのコストをできる限り小さくすることを意味します。
41+ Rustはそれらの目標を、様々な「ゼロコスト抽象化」を通じて成し遂げます。
42+ それは、Rustでは抽象化を機能させるためのコストをできる限り小さくすることを意味します。
4243所有権システムはゼロコスト抽象化の主な例です。
4344このガイドの中で話すであろう解析の全ては _ コンパイル時に行われます_ 。
4445それらのどの機能に対しても実行時のコストは全く掛かりません。
@@ -53,9 +54,11 @@ Rustはそれらの目標をたくさんの「ゼロコスト抽象化」を通
5354<!-- rules of the ownership system for a period of time, they fight the borrow -->
5455<!-- checker less and less. -->
5556しかし、このシステムはあるコストを持ちます。それは学習曲線です。
56- 多くの新しいRustのユーザは「借用チェッカとの戦い」と好んで呼ばれるものを経験します。そこではRustコンパイラが開発者が正しいと考えるプログラムをコンパイルすることを拒絶します。
57+ 多くのRust入門者は、私たちが「借用チェッカとの戦い」と呼ぶものを経験します。
58+ そこではRustコンパイラが、開発者が正しいと考えるプログラムをコンパイルすることを拒絶します。
5759所有権がどのように機能するのかについてのプログラマのメンタルモデルがRustの実装する実際のルールにマッチしないため、これはしばしば起きます。
58- しかし、よいニュースがあります。より経験豊富なRustの開発者は次のことを報告します。一度彼らが所有権システムのルールとともにしばらく仕事をすれば、彼らが借用チェッカと戦うことは少なくなっていくということです。
60+ しかし、よいニュースがあります。より経験豊富なRustの開発者は次のことを報告します。
61+ それは、所有権システムのルールと共にしばらく仕事をすれば、借用チェッカと戦うことは次第に少なくなっていく、というものです。
5962
6063<!-- With that in mind, let’s learn about lifetimes. -->
6164それを念頭に置いて、所有権について学びましょう。
@@ -80,19 +83,19 @@ Rustはそれらの目標をたくさんの「ゼロコスト抽象化」を通
8083
8184<!-- Uh oh! Your reference is pointing to an invalid resource. This is called a -->
8285<!-- dangling pointer or ‘use after free’, when the resource is memory. -->
83- あー!
84- あなたの参照は無効なリソースを指示しています 。
85- リソースがメモリであるとき、これはダングリングポインタ又は 「解放後の使用」と呼ばれます。
86+ あー!
87+ あなたの参照は無効なリソースを指しています 。
88+ リソースがメモリであるとき、これはダングリングポインタまたは 「解放後の使用」と呼ばれます。
8689
8790<!-- To fix this, we have to make sure that step four never happens after step -->
8891<!-- three. The ownership system in Rust does this through a concept called -->
8992<!-- lifetimes, which describe the scope that a reference is valid for. -->
9093これを修正するためには、ステップ3の後にステップ4が絶対に起こらないようにしなければなりません。
9194Rustでの所有権システムはこれをライフタイムと呼ばれる概念を通じて行います。それは参照の有効なスコープを記述するものです。
9295
93- <!-- When we have a function that takes a reference by argument , we can be implicit -->
94- <!-- or explicit about the lifetime of the reference: -->
95- 引数として参照を受け取る関数について、参照のライフタイムを黙示又は明示することができます 。
96+ <!-- When we have a function that takes an argument by reference , we can be -->
97+ <!-- implicit or explicit about the lifetime of the reference: -->
98+ 引数として参照を受け取る関数について、参照のライフタイムを黙示または明示できます 。
9699
97100``` rust
98101# // implicit
@@ -124,10 +127,10 @@ fn bar<'a>(...)
124127<!-- discuss the `<>`s after a function’s name. A function can have ‘generic -->
125128<!-- parameters’ between the `<>`s, of which lifetimes are one kind. We’ll discuss -->
126129<!-- other kinds of generics [later in the book][generics], but for now, let’s -->
127- <!-- just focus on the lifetimes aspect. -->
130+ <!-- focus on the lifetimes aspect. -->
128131[ 関数の構文] [ functions ] については前に少し話しました。しかし、関数名の後の ` <> ` については議論しませんでした。
129132関数は ` <> ` の間に「ジェネリックパラメータ」を持つことができ、ライフタイムはその一種です。
130- 他の種類のジェネリクスについては [ 本書の後の方] [ generics ] で議論しますが、とりあえず、ライフタイムの面だけに焦点を合わせましょう 。
133+ 他の種類のジェネリクスについては [ 本書の後の方] [ generics ] で議論しますが、とりあえず、ライフタイムの面に焦点を合わせましょう 。
131134
132135[ functions ] : functions.html
133136[ generics ] : generics.html
@@ -149,14 +152,14 @@ fn bar<'a, 'b>(...)
149152...(x: &'a i32)
150153```
151154
152- <!-- If we wanted an `&mut` reference, we’d do this: -->
155+ <!-- If we wanted a `&mut` reference, we’d do this: -->
153156もし ` &mut ` 参照が欲しいのならば、次のようにします。
154157
155158``` rust,ignore
156159...(x: &'a mut i32)
157160```
158161
159- <!-- If you compare `&mut i32` to `&'a mut i32`, they’re the same, it’s just that -->
162+ <!-- If you compare `&mut i32` to `&'a mut i32`, they’re the same, it’s that -->
160163<!-- the lifetime `'a` has snuck in between the `&` and the `mut i32`. We read `&mut -->
161164<!-- i32` as ‘a mutable reference to an `i32`’ and `&'a mut i32` as ‘a mutable -->
162165<!-- reference to an `i32` with the lifetime `'a`’. -->
@@ -187,7 +190,7 @@ fn main() {
187190[ structs ] : structs.html
188191
189192<!-- As you can see, `struct`s can also have lifetimes. In a similar way to functions, -->
190- 見てのとおり、 ` struct ` もライフタイムを持つことができます 。
193+ 見てのとおり、 ` struct ` もライフタイムを持てます 。
191194これは関数と同じ方法です。
192195
193196``` rust
@@ -236,16 +239,16 @@ fn main() {
236239```
237240
238241<!-- As you can see, we need to declare a lifetime for `Foo` in the `impl` line. We repeat -->
239- <!-- `'a` twice, just like on functions: `impl<'a>` defines a lifetime `'a`, and `Foo<'a>` -->
242+ <!-- `'a` twice, like on functions: `impl<'a>` defines a lifetime `'a`, and `Foo<'a>` -->
240243<!-- uses it. -->
241244見てのとおり、 ` Foo ` のライフタイムは ` impl ` 行で宣言する必要があります。
242- ちょうど関数のときのように ` 'a ` は2回繰り返されます。つまり、 ` impl<'a> ` はライフタイム ` 'a ` を定義し、 ` Foo<'a> ` はそれを使うのです。
245+ 関数のときのように ` 'a ` は2回繰り返されます。つまり、 ` impl<'a> ` はライフタイム ` 'a ` を定義し、 ` Foo<'a> ` はそれを使うのです。
243246
244247<!-- ## Multiple lifetimes -->
245248## 複数のライフタイム
246249
247250<!-- If you have multiple references, you can use the same lifetime multiple times: -->
248- もし複数の参照があれば、同じライフタイムを複数回使うことができます 。
251+ もし複数の参照があるなら、同じライフタイムを何度でも使えます 。
249252
250253``` rust
251254fn x_or_y <'a >(x : & 'a str , y : & 'a str ) -> & 'a str {
@@ -257,7 +260,7 @@ fn x_or_y<'a>(x: &'a str, y: &'a str) -> &'a str {
257260<!-- return value is also alive for that scope. If you wanted `x` and `y` to have -->
258261<!-- different lifetimes, you can use multiple lifetime parameters: -->
259262これは ` x ` と ` y ` が両方とも同じスコープで有効であり、戻り値もそのスコープで有効であることを示します。
260- もし ` x ` と ` y ` に違うライフタイムを持たせたいのであれば、複数のライフタイムパラメータを使うことができます 。
263+ もし ` x ` と ` y ` に違うライフタイムを持たせたいのであれば、複数のライフタイムパラメータを使えます 。
261264
262265``` rust
263266fn x_or_y <'a , 'b >(x : & 'a str , y : & 'b str ) -> & 'a str {
@@ -349,14 +352,14 @@ fn main() {
349352<!-- Whew! As you can see here, the scopes of `f` and `y` are smaller than the scope -->
350353<!-- of `x`. But when we do `x = &f.x`, we make `x` a reference to something that’s -->
351354<!-- about to go out of scope. -->
352- ふう!
355+ ふう!
353356見てのとおり、ここでは ` f ` と ` y ` のスコープは ` x ` のスコープよりも小さいです。
354357しかし ` x = &f.x ` を実行するとき、 ` x ` をまさにスコープから外れた何かの参照にしてしまいます。
355358
356359<!-- Named lifetimes are a way of giving these scopes a name. Giving something a -->
357360<!-- name is the first step towards being able to talk about it. -->
358361名前の付いたライフタイムはそれらのスコープに名前を与える方法です。
359- 何かに名前を与えることはそれについて話をすることができるようになるための最初のステップです 。
362+ 何かに名前を与えることはそれについて話をできるようになるための最初のステップです 。
360363
361364<!-- ## 'static -->
362365## 'static
@@ -390,19 +393,18 @@ let x: &'static i32 = &FOO;
390393<!-- ## Lifetime Elision -->
391394## ライフタイムの省略
392395
393- <!-- Rust supports powerful local type inference in function bodies, but it’s -->
394- <!-- forbidden in item signatures to allow reasoning about the types based on -->
395- <!-- the item signature alone. However, for ergonomic reasons a very restricted -->
396- <!-- secondary inference algorithm called “lifetime elision” applies in function -->
397- <!-- signatures. It infers only based on the signature components themselves and not -->
398- <!-- based on the body of the function, only infers lifetime parameters, and does -->
399- <!-- this with only three easily memorizable and unambiguous rules. This makes -->
400- <!-- lifetime elision a shorthand for writing an item signature, while not hiding -->
396+ <!-- Rust supports powerful local type inference in the bodies of functions but not in their item signatures. -->
397+ <!-- It's forbidden to allow reasoning about types based on the item signature alone. -->
398+ <!-- However, for ergonomic reasons, a very restricted secondary inference algorithm called -->
399+ <!-- “lifetime elision” does apply when judging lifetimes. Lifetime elision is concerned solely to infer -->
400+ <!-- lifetime parameters using three easily memorizable and unambiguous rules. This means lifetime elision -->
401+ <!-- acts as a shorthand for writing an item signature, while not hiding -->
401402<!-- away the actual types involved as full local inference would if applied to it. -->
402- Rustは関数本体の部分では強力なローカル型推論をサポートします。しかし要素のシグネチャの部分では、型が要素のシグネチャだけでわかるようにするため、(型推論が)許されていません。
403- とはいえ、エルゴノミック(人間にとっての扱いやすさ)の理由により、"ライフタイムの省略"と呼ばれている、非常に制限された第二の推論アルゴリズムがシグネチャの部分に適用されます。
404- その推論はシグネチャのコンポーネントだけに基づき、関数本体には基づかず、ライフタイムパラメータだけを推論します。そしてたった3つの覚えやすく明確なルールに従って行います。
405- ライフタイムの省略で要素のシグネチャを短く書くことができます。しかしローカル型推論が適用されるときのように実際の型を隠すことはできません。
403+ Rustは関数本体については強力なローカル型推論をサポートしますが、要素のシグネチャについては別です。
404+ そこで型推論が許されていないのは、要素のシグネチャだけで型がわかるようにするためです。
405+ とはいえ、エルゴノミック(人間にとっての扱いやすさ)上の理由により、ライフタイムを決定する際には、「ライフタイムの省略」と呼ばれる、非常に制限された第二の推論アルゴリズムが適用されます。
406+ ライフタイムの推論は、ライフタイムパラメータの推論だけに関係しており、たった3つの覚えやすく明確なルールに従います。
407+ ライフタイムの省略は要素のシグネチャを短く書けることを意味しますが、ローカル型推論が適用されるときのように実際の型を隠すことはできません。
406408
407409<!-- When talking about lifetime elision, we use the term *input lifetime* and -->
408410<!-- *output lifetime*. An *input lifetime* is a lifetime associated with a parameter -->
@@ -431,19 +433,19 @@ fn foo<'a>(bar: &'a str) -> &'a str
431433```
432434
433435<!-- Here are the three rules: -->
434- これが3つのルールです 。
436+ 3つのルールを以下に示します 。
435437
436438<!-- * Each elided lifetime in a function’s arguments becomes a distinct lifetime -->
437439<!-- parameter. -->
438- * 関数の引数の中の省略された各ライフタイムは互いに異なるライフタイムパラメータになる
440+ * 関数の引数の中の省略された各ライフタイムは、互いに異なるライフタイムパラメータになる
439441
440442<!-- * If there is exactly one input lifetime, elided or not, that lifetime is -->
441443<!-- assigned to all elided lifetimes in the return values of that function. -->
442444* もし入力ライフタイムが1つだけならば、省略されたかどうかにかかわらず、そのライフタイムはその関数の戻り値の中の省略されたライフタイム全てに割り当てられる
443445
444446<!-- * If there are multiple input lifetimes, but one of them is `&self` or `&mut -->
445447<!-- self`, the lifetime of `self` is assigned to all elided output lifetimes. -->
446- * もし入力ライフタイムが複数あるが、その1つが ` &self ` 又は ` &mut self ` であれば、 ` self ` のライフタイムは省略された出力ライフタイム全てに割り当てられる
448+ * もし入力ライフタイムが複数あるが、その1つが ` &self ` または ` &mut self ` であれば、 ` self ` のライフタイムは省略された出力ライフタイム全てに割り当てられる
447449
448450<!-- Otherwise, it is an error to elide an output lifetime. -->
449451そうでないときは、出力ライフタイムの省略はエラーです。
@@ -492,10 +494,10 @@ fn frob<'a, 'b>(s: &'a str, t: &'b str) -> &str; // 展開された形。出力
492494fn get_mut(&mut self) -> &mut T; // 省略された形
493495fn get_mut<'a>(&'a mut self) -> &'a mut T; // 展開された形
494496
495- # // fn args<T:ToCStr>(&mut self, args: &[T]) -> &mut Command; // elided
496- # // fn args<'a, 'b, T:ToCStr>(&'a mut self, args: &'b [T]) -> &'a mut Command; // expanded
497- fn args<T:ToCStr>(&mut self, args: &[T]) -> &mut Command; // 省略された形
498- fn args<'a, 'b, T:ToCStr>(&'a mut self, args: &'b [T]) -> &'a mut Command; // 展開された形
497+ # // fn args<T: ToCStr>(&mut self, args: &[T]) -> &mut Command; // elided
498+ # // fn args<'a, 'b, T: ToCStr>(&'a mut self, args: &'b [T]) -> &'a mut Command; // expanded
499+ fn args<T: ToCStr>(&mut self, args: &[T]) -> &mut Command; // 省略された形
500+ fn args<'a, 'b, T: ToCStr>(&'a mut self, args: &'b [T]) -> &'a mut Command; // 展開された形
499501
500502# // fn new(buf: &mut [u8]) -> BufWriter; // elided
501503# // fn new<'a>(buf: &'a mut [u8]) -> BufWriter<'a>; // expanded
0 commit comments