和訳の修正

second-edition/src/ch04-01-what-is-ownership.md

@@ -112,7 +112,7 @@ Rustと所有権システムの規則と経験を積むにつれて、自然に
 >
 > スタックもヒープも、実行時にコードが使用できるメモリの一部になりますが、異なる手段で構成されています。
 > スタックは、得た順番に値を並べ、逆の順で値を取り除いていきます。これは、
-> *last in, first out*(`訳注`: あえて日本語にするなら、けつ入れ頭出しといったところでしょうか)と呼ばれます。
+> *last in, first out*(`訳注`: あえて日本語にするなら、「最後に入れたものが最初に出てくる」といったところでしょうか)と呼ばれます。
 > お皿の山を思い浮かべてください: お皿を追加する時には、山の一番上に置き、お皿が必要になったら、一番上から1枚を取り去りますよね。
 > 途中や一番下に追加したり、取り除いたりすることもできません。データを追加することは、
 > *スタックにpushする*といい、データを取り除くことは、*スタックからpopする*と表現します(`訳注`:
@@ -125,8 +125,8 @@ Rustと所有権システムの規則と経験を積むにつれて、自然に
 > コンパイル時にサイズがわからなかったり、サイズが可変のデータについては、代わりにヒープに格納することができます。
 > ヒープは、もっとごちゃごちゃしています: ヒープにデータを置く時、あるサイズのスペースを求めます。
 > OSはヒープ上に十分な大きさの空の領域を見つけ、使用中にし、*ポインタ*を返してきます。ポインタとは、その場所へのアドレスです。
-> この過程は、*ヒープに領域を確保する*と呼ばれ、時としてそのフレーズを単に*allocateする*などと省略したりします。
-> (`訳注`: こちらもこなれた日本語訳はないでしょう。allocateはメモリを確保すると訳したいところですが)
+> この過程は、*ヒープに領域を確保する(allocating on the heap)*と呼ばれ、時としてそのフレーズを単に*allocateする*などと省略したりします。
+> (`訳注`: こちらもこなれた日本語訳はないでしょう。allocateは「メモリを確保する」と訳したいところですが)
 > スタックに値を載せることは、メモリ確保とは考えられません。ポインタは、既知の固定サイズなので、
 > スタックに保管することができますが、実データが必要になったら、ポインタを追いかける必要があります。
 >
@@ -564,7 +564,8 @@ do if Rust copied the heap data as well</span> -->
 その変数が使っていたヒープメモリを片付けると述べました。しかし、図4-2は、
 両方のデータポインタが同じ場所を指していることを示しています。これは問題です: `s2`と`s1`がスコープを抜けたら、
 両方とも同じメモリを解放しようとします。これは*二重解放*エラーとして知られ、以前触れたメモリ安全性上のバグの一つになります。
-メモリを2回解放することは、メモリの退廃につながり、さらにセキュリティ上の脆弱性を生む可能性があります。
+メモリを2回解放することは、memory corruption (`訳注`: メモリの崩壊。意図せぬメモリの書き換え) につながり、
+セキュリティ上の脆弱性を生む可能性があります。
 
 <!-- To ensure memory safety, there’s one more detail to what happens in this -->
 <!-- situation in Rust. Instead of trying to copy the allocated memory, Rust -->
@@ -672,7 +673,7 @@ println!("s1 = {}, s2 = {}", s1, s2);
 <!-- This works just fine and explicitly produces the behavior shown in Figure 4-3, -->
 <!-- where the heap data *does* get copied. -->
 
-これは単純にうまく動き、図4-3で示した動作を明示的に生み出します。ここでは、
+これは問題なく動作し、図4-3で示した動作を明示的に生み出します。ここでは、
 ヒープデータが*実際に*コピーされています。
 
 <!-- When you see a call to `clone`, you know that some arbitrary code is being -->
@@ -752,9 +753,9 @@ Rustには`Copy`トレイトと呼ばれる特別な注釈があり、
 <!-- `(i32, i32)` is `Copy`, but `(i32, String)` is not. -->
 
 * あらゆる整数型。`u32`など。
-* 論理値型、`bool`、`true`と`false`という値がある。
+* 論理値型である`bool`。`true`と`false`という値がある。
 * あらゆる浮動小数点型、`f64`など。
-* 文字型、`char`。
+* 文字型である`char`。
 * タプル。ただ、`Copy`の型だけを含む場合。例えば、`(i32, i32)`は`Copy`だが、
 `(i32, String)`は違う。
 

second-edition/src/ch04-03-slices.md

@@ -201,8 +201,8 @@ fn main() {
 <!-- we write a `second_word` function. Its signature would have to look like this: -->
 
 `word`内の添え字が`s`に格納されたデータと同期されなくなるのを心配することは、面倒ですし間違いになりやすいです！
-これらの添え字を管理するのは、`second_word`関数を書いたら、さらに脆くなります。
-そのシグニチャは以下のようにならなければおかしいです:
+これらの添え字の管理は、`second_word`関数を書いたら、さらに難しくなります。
+そのシグニチャは以下のようになるはずです:
 
 ```rust,ignore
 fn second_word(s: &String) -> (usize, usize) {
@@ -214,7 +214,7 @@ fn second_word(s: &String) -> (usize, usize) {
 <!-- need to be kept in sync. -->
 
 今、私たちは開始*と*終端の添え字を追うようになりました。特定の状態のデータから計算されたけど、
-その状態に全く紐付かない値が増えました。同期を取る必要のある宙に浮いた関連性のない変数が3つになってしまいました。
+その状態に全く紐付かない値が増えました。いつの間にか変わってしまうので、同期を取る必要のある、関連性のない変数が3つになってしまいました。
 
 <!-- Luckily, Rust has a solution to this problem: string slices. -->
 
@@ -355,7 +355,7 @@ fn first_word(s: &String) -> &str {
 <!-- as the starting and ending indices. -->
 
 リスト4-7で取った手段と同じ方法で単語の終端添え字を取得しています。つまり、最初の空白を探すことです。
-空白を発見したら、文字列の最初と、空白の添え字を開始、終了地点として使用して文字列スライスを返しています。
+空白を発見したら、文字列の最初を開始地点、空白の添え字を終了地点として使用して文字列スライスを返しています。
 
 <!-- Now when we call `first_word`, we get back a single value that is tied to the -->
 <!-- underlying data. The value is made up of a reference to the starting point of -->

second-edition/src/ch05-02-example-structs.md

@@ -208,7 +208,7 @@ fn area(rectangle: &Rectangle) -> u32 {
 `area`関数は、`Rectangle`インスタンスの`width`と`height`フィールドにアクセスしています。
 これで、`area`の関数シグニチャは、我々の意図をズバリ示すようになりました: `width`と`height`フィールドを使って、
 `Rectangle`の面積を計算します。これにより、幅と高さが相互に関係していることが伝わり、
-タプルの`0`や`1`という添え字を使うのではなく、値に説明的な名前を与えられるのです。簡潔性を勝ち取ったわけですね。
+タプルの`0`や`1`という添え字を使うよりも、これらの値に説明的な名前を与えられるのです。プログラムの意図が明瞭になりました。
 
 <!-- ### Adding Useful Functionality with Derived Traits -->
 

second-edition/src/ch05-03-method-syntax.md

@@ -197,8 +197,8 @@ fn main() {
 >
 > 前者の方がずっと明確です。メソッドには自明な受け手(`self`の型)がいるので、この自動参照機能は動作するのです。
 > 受け手とメソッド名が与えられれば、コンパイラは確実にメソッドが読み込み専用(`&self`)か、書き込みもする(`&mut self`)のか、
-> 所有権を奪う(`self`)のか判断できるわけです。Rustにおいて、メソッドの受け手に関して借用が明示されないという事実は、
-> 所有権を現実世界でエルゴノミックにさせる大部分を占めているのです。
+> 所有権を奪う(`self`)のか判断できるわけです。メソッドの受け手に関して借用が明示されないというのが、
+> 所有権を実際に使うのがRustにおいて簡単である大きな理由です。
 
 <!-- ### Methods with More Parameters -->
 

second-edition/src/ch06-01-defining-an-enum.md

@@ -253,15 +253,15 @@ enum IpAddr {
 
 このコードは、enum列挙子内にいかなる種類のデータでも格納できることを描き出しています:
 例を挙げれば、文字列、数値型、構造体などです。他のenumを含むことさえできます！また、
-標準ライブラリの型は、あなたが思い付いた可能性のあるものよりも複雑ではないことがしばしばあります。
+標準ライブラリの型は、あなたの想像するよりも複雑ではないことがしばしばあります。
 
 <!-- Note that even though the standard library contains a definition for `IpAddr`, -->
 <!-- we can still create and use our own definition without conflict because we -->
 <!-- haven’t brought the standard library’s definition into our scope. We’ll talk -->
 <!-- more about bringing types into scope in Chapter 7. -->
 
-標準ライブラリに`IpAddr`に対する定義は含まれるものの、標準ライブラリの定義をスコープに導入していないので、
-まだ、干渉することなく自分自身の定義を生成して使用できることに注意してください。型をスコープに導入することについては、
+標準ライブラリに`IpAddr`に対する定義は含まれるものの、標準ライブラリの定義をまだ我々のスコープに導入していないので、
+干渉することなく自分自身の定義を生成して使用できることに注意してください。型をスコープに導入することについては、
 第7章でもっと詳しく言及します。
 
 <!-- Let’s look at another example of an enum in Listing 6-2: this one has a wide -->

second-edition/src/ch06-02-match.md

@@ -390,9 +390,9 @@ error[E0004]: non-exhaustive patterns: `None` not covered
 
 全可能性を網羅していないことをコンパイラは検知しています。もっと言えば、どのパターンを忘れているかさえ知っているのです。
 Rustにおけるマッチは、*包括的*です: 全てのあらゆる可能性を網羅し尽くさなければ、コードは有効にならないのです。
-特に`Option<T>`の場合には、コンパイラが明示的に`None`の場合を扱うのを忘れないようにする時、
-nullになるかもしれない値があることを想定しないように、故に、前に議論した10億ドルの失敗を犯さないよう、
-保護してくれるわけです。
+特に`Option<T>`の場合には、私達が明示的に`None`の場合を処理するのを忘れないようにしてくれます。
+nullになるかもしれないのに値があると思い込まないよう、すなわち前に議論した10億ドルの失敗を犯さないよう、
+コンパイラが保護してくれるわけです。
 
 <!-- ### The `_` Placeholder -->