Reflect recent changes to the book (#20)

Author: Ken Kawamoto

docs/exotic-sizes.html

@@ -178,23 +178,23 @@ <h1><a class="header" href="#動的サイズの型dst-dynamically-sized-type" id
 <!--
 There are two major DSTs exposed by the language: trait objects, and slices.
 -->
-<p>言語が提供する DST のうち重要なものが 2 つあります。trait オブジェクトとスライスです。</p>
+<p>言語が提供する DST のうち重要なものが 2 つあります。トレイトオブジェクトとスライスです。</p>
 <!--
 A trait object represents some type that implements the traits it specifies.
 The exact original type is *erased* in favor of runtime reflection
 with a vtable containing all the information necessary to use the type.
 This is the information that completes a trait object: a pointer to its vtable.
 -->
-<p>Trait オブジェクトは、それが指す Trait を実装するある型を表現します。
+<p>トレイトオブジェクトは、それが指すトレイトを実装するある型を表現します。
 元となった型は消去されますが、vtable とリフレクションとによって実行時にはその型を利用することができます。
 つまり、Trait オブジェクトを補完する情報とは vtable へのポインタとなります。</p>
 <!--
 A slice is simply a view into some contiguous storage -- typically an array or
 `Vec`. The information that completes a slice is just the number of elements
 it points to.
 -->
-<p>スライスとは、単純にある連続したスペース（通常はアレイか <code>Vec</code>）のビューです。
-スライスを補完する情報とは、単にポインタが指すエレメントの数です。</p>
+<p>スライスとは、単純にある連続したスペース（通常は配列か <code>Vec</code>）のビューです。
+スライスを補完する情報とは、単にポインタが指す要素の数です。</p>
 <!--
 Structs can actually store a single DST directly as their last field, but this
 makes them a DST as well:
@@ -231,8 +231,8 @@ <h1><a class="header" href="#サイズが-0-の型zst-zero-sized-type" id="サ
 // すべてのフィールドのサイズがない = サイズ 0
 struct Baz {
     foo: Foo,
-    qux: (),      // empty tuple has no size
-    baz: [u8; 0], // empty array has no size
+    qux: (),      // 空のタプルにはサイズがありません
+    baz: [u8; 0], // 空の配列にはサイズがありません
 }
 #}</code></pre></pre>
 <!--
@@ -244,7 +244,7 @@ <h1><a class="header" href="#サイズが-0-の型zst-zero-sized-type" id="サ
 type, so anything that loads it can just produce it from the  aether -- which is
 also a no-op since it doesn't occupy any space.
 -->
-<p>サイズ 0 の型（ZST）は、当然ながら、それ自体ではほとんど価値があありません。
+<p>サイズ 0 の型（ZST）は、当然ながら、それ自体ではほとんど価値がありません。
 しかし、多くの興味深いレイアウトの選択肢と組み合わせると、ZST が潜在的に役に立つことがいろいろな
 ケースで明らかになります。Rust は、ZST を生成したり保存したりするオペレーションが no-op に
 還元できることを理解しています。
@@ -261,7 +261,7 @@ <h1><a class="header" href="#サイズが-0-の型zst-zero-sized-type" id="サ
 -->
 <p>究極の ZST の利用法として、Set と Map を考えてみましょう。
 <code>Map&lt;Key, Value&gt;</code> があるときに、<code>Set&lt;Key&gt;</code> を <code>Map&lt;Key, UselessJunk&gt;</code> の
-簡単なラッパーとして実装することはよくあります。
+簡単なラッパとして実装することはよくあります。
 多くの言語では、UselessJunk のスペースを割り当てる必要があるでしょうし、
 結果的に使わない UselessJunk を保存したり読み込んだりする必要もあるでしょう。
 こういったことが不要であると示すのはコンパイラにとっては難しい仕事でしょう。</p>
@@ -283,7 +283,7 @@ <h1><a class="header" href="#サイズが-0-の型zst-zero-sized-type" id="サ
 may return `nullptr` when a zero-sized allocation is requested, which is
 indistinguishable from out of memory.
 -->
-<p>安全なコードは ZST について心配する必要はありませんが、<em>危険な</em> コードは
+<p>安全なコードは ZST について心配する必要はありませんが、<em>アンセーフな</em>コードは
 サイズ 0 の型を使った時の結果について注意しなくてはなりません。
 特に、ポインタのオフセットは no-op になることや、
 （Rust のデフォルトである jemalloc を含む）標準的なメモリアロケータは、
@@ -321,7 +321,7 @@ <h1><a class="header" href="#空の型" id="空の型">空の型</a></h1>
 特定のケースでは絶対に失敗しないことがわかっているとします。
 <code>Result&lt;T, Void&gt;</code> を返すことで、この事実を型レベルで伝えることが可能です。
 Void 型の値を提供することはできないので、この Result は Err に<em>なり得ないと静的にわかります</em>。
-そのため、この API の利用者は、自信を持って Result を unwrap することができます。</p>
+そのため、この API の利用者は、自信を持って Result をアンラップすることができます。</p>
 <!--
 In principle, Rust can do some interesting analyses and optimizations based
 on this fact. For instance, `Result<T, Void>` could be represented as just `T`,
@@ -343,18 +343,18 @@ <h1><a class="header" href="#空の型" id="空の型">空の型</a></h1>
 the ability to be confident that certain situations are statically impossible.
 -->
 <p>ただし、どちらの例も現時点では動きません。
-つまり、Void 型による利点は、静的な解析によて、特定の状況が起こらないと確実に言えることだけです。</p>
+つまり、Void 型による利点は、静的な解析によって、特定の状況が起こらないと確実に言えることだけです。</p>
 <!--
 One final subtle detail about empty types is that raw pointers to them are
 actually valid to construct, but dereferencing them is Undefined Behavior
 because that doesn't actually make sense. That is, you could model C's `void *`
 type with `*const Void`, but this doesn't necessarily gain anything over using
 e.g. `*const ()`, which *is* safe to randomly dereference.
 -->
-<p>最後に細かいことを一つ。空の型を指す生のポインタを構成することは有効ですが、
-それをデリファレンスすることは、意味がないので、未定義の挙動となります。
+<p>最後に細かいことを一つ。空の型を指す生ポインタを構成することは有効ですが、
+それを参照外しすることは、意味がないので、未定義の挙動となります。
 つまり、C における <code>void *</code> と同じような意味で <code>*const Void</code> を使うこと出来ますが、
-これは、<em>安全に</em>デリファレンスできる型（例えば <code>*const ()</code>）と比べて何も利点はありません。</p>
+これは、<em>安全に</em>参照外しできる型（例えば <code>*const ()</code>）と比べて何も利点はありません。</p>
 
                     </main>
 

docs/meet-safe-and-unsafe.html

@@ -199,7 +199,7 @@ <h1><a class="header" href="#安全と危険のご紹介" id="安全と危険の
 -->
 <p>安全な Rust は真の Rust プログラミング言語です。もしあなたが安全な Rust だけでコードを書くなら、
 型安全やメモリ安全性などを心配する必要はないでしょう。
-null ポインタや dangling ポインタ、馬鹿げた「未定義な挙動」などに我慢する必要はないのです。</p>
+ヌルポインタやダングリングポインタ、馬鹿げた「未定義な挙動」などに我慢する必要はないのです。</p>
 <!--
 *That's totally awesome.*
 -->
@@ -241,9 +241,9 @@ <h1><a class="header" href="#安全と危険のご紹介" id="安全と危険の
 * Mutate statics
 -->
 <ul>
-<li>生のポインタが指す値を得る</li>
-<li><code>unsafe</code> な関数を呼ぶ（C 言語で書かれた関数や、intrinsics、生のアロケータなど）</li>
-<li><code>unsafe</code> な trait を実装する</li>
+<li>生ポインタが指す値を得る</li>
+<li><code>unsafe</code> な関数を呼ぶ（C 言語で書かれた関数や、intrinsic、生のアロケータなど）</li>
+<li><code>unsafe</code> なトレイトを実装する</li>
 <li>静的な構造体を変更する</li>
 </ul>
 <!--
@@ -276,15 +276,15 @@ <h1><a class="header" href="#安全と危険のご紹介" id="安全と危険の
 * Causing a [data race][race]
 -->
 <ul>
-<li>null ポインタや dangling ポインタのデリファレンス</li>
+<li>ヌルポインタやダングリングポインタの参照外し</li>
 <li><a href="uninitialized.html">未初期化のメモリ</a> を読む</li>
 <li><a href="references.html">ポインタエイリアスルール</a> を破る</li>
 <li>不正なプリミティブな値を生成する
 <ul>
-<li>dangling リファレンス、null リファレンス</li>
+<li>ダングリング参照、ヌル参照</li>
 <li>0 でも 1 でもない <code>bool</code> 値</li>
 <li>未定義な <code>enum</code> 判別式</li>
-<li>[0x0, 0xD7FF] と [0xE000, 0x10FFFF] 範囲外の <code>char</code> 値 </li>
+<li>[0x0, 0xD7FF] と [0xE000, 0x10FFFF] 範囲外の <code>char</code> 値</li>
 <li>utf8 ではない <code>str</code> 値</li>
 </ul>
 </li>
@@ -300,9 +300,9 @@ <h1><a class="header" href="#安全と危険のご紹介" id="安全と危険の
 intrinsics that make special assumptions about how code can be optimized.
 -->
 <p>これだけです。これが、Rust が防ぐ「未定義な挙動」の原因です。
-もちろん、危険な関数や trait が「未定義な挙動」を起こさないための他の制約を作り出す事は可能ですが、
+もちろん、危険な関数やトレイトが「未定義な挙動」を起こさないための他の制約を作り出す事は可能ですが、
 そういった制約が破られた場合、たいてい上の問題のどれかを引き起こします。
-コンパイラ intrinsics がその他の制約を生み出し、コードの最適化に関する特別な仮定をすることもあります。</p>
+コンパイラ intrinsic がその他の制約を生み出し、コードの最適化に関する特別な仮定をすることもあります。</p>
 <!--
 Rust is otherwise quite permissive with respect to other dubious operations.
 Rust considers it "safe" to:
@@ -333,7 +333,7 @@ <h1><a class="header" href="#安全と危険のご紹介" id="安全と危険の
 these problems are considered impractical to categorically prevent.
 -->
 <p>とはいえ、こういうことをできてしまうプログラムは<em>恐らく</em>間違っていると言えるでしょう。
-Rust はこういった事をおきにくくするためのツールをたくさん提供します。
+Rust はこういった事を起きにくくするためのツールをたくさん提供します。
 しかし、これらの問題を完全に防ぐのは現実的ではないと考えられています。</p>
 
                     </main>

docs/other-reprs.html

@@ -213,8 +213,8 @@ <h1><a class="header" href="#repru8-repru16-repru32-repru64" id="repru8-repru16-
 On non-C-like enums, this will inhibit certain optimizations like the null-
 pointer optimization.
 -->
-<p>C っぽくない enum （訳注：要素がパラメタをとるような enum）に <code>repr(u*)</code> を適用すると、
-null ポインタ最適化のようなある種の最適化ができなくなります。</p>
+<p>C っぽくない enum （訳注：要素がパラメータをとるような enum）に <code>repr(u*)</code> を適用すると、
+ヌルポインタ最適化のようなある種の最適化ができなくなります。</p>
 <!--
 These reprs have no effect on a struct.
 -->
@@ -228,7 +228,7 @@ <h1><a class="header" href="#reprpacked" id="reprpacked">repr(packed)</a></h1>
 byte. This may improve the memory footprint, but will likely have other negative
 side-effects.
 -->
-<p><code>repr(packed)</code> を使うと Rust はパディングを一切取り除き、すべてを byte 単位にアラインします。
+<p><code>repr(packed)</code> を使うと Rust はパディングを一切取り除き、すべてをバイト単位にアラインします。
 メモリ使用量は改善しますが、悪い副作用を引き起こす可能性が高いです。</p>
 <!--
 In particular, most architectures *strongly* prefer values to be aligned. This
@@ -238,17 +238,17 @@ <h1><a class="header" href="#reprpacked" id="reprpacked">repr(packed)</a></h1>
 However if you take a reference to a packed field, it's unlikely that the
 compiler will be able to emit code to avoid an unaligned load.
 -->
-<p>特にほとんどのアークテクチャは、値がアラインされていることを<em>強く</em>望んでいます。
+<p>特にほとんどのアーキテクチャは、値がアラインされていることを<em>強く</em>望んでいます。
 つまりアラインされていないデータの読み込みにはペナルティがある（x86）かもしれませんし、
 失敗する（いくつかの ARM チップ）かもしれません。
 パックされたフィールドを直接読んだり書いたりするという単純なケースでは、
 コンパイラがシフトやマスクを駆使してアラインメントの問題を隠してくれるかもしれません。
-しかし、パックされたフィールドへのリファレンスを扱う場合には、アラインされてない読み込みを避けるような
+しかし、パックされたフィールドへの参照を扱う場合には、アラインされてない読み込みを避けるような
 コードをコンパイラが生成することは期待できないでしょう。</p>
 <p><strong><a href="https://github.com/rust-lang/rust/issues/27060">Rust 1.0 時点では、これは未定義な挙動です。</a></strong></p>
 <p><code>repr(packed)</code> は気軽に使えるものではありません。
 極端な要求に応えようとしているのでない限り、使うべきではありません。</p>
-<p>この repr は <code>repr(C)</code> や <code>repr(rust)</code> の就職誌として使えます。</p>
+<p>この repr は <code>repr(C)</code> や <code>repr(rust)</code> の修飾子として使えます。</p>
 
                     </main>
 

docs/ownership.html

@@ -185,7 +185,7 @@ <h1><a class="header" href="#所有権とライフタイム" id="所有権とラ
     let s = format!(&quot;{}&quot;, data);
 
     // しまった! この関数内でしか存在しないオブジェクトへの
-    // リファレンスを返してしまった!
+    // 参照を返してしまった!
     // ダングリングポインタだ! メモリ解放後の参照だ! うわーー!
     // （このコードは Rust ではコンパイルエラーになります）
     &amp;s
@@ -217,12 +217,12 @@ <h1><a class="header" href="#所有権とライフタイム" id="所有権とラ
 because ensuring pointers are always valid is much more complicated than this.
 For instance in this code,
 -->
-<p>もちろん、リファレンスが参照先のスコープから逃げ出していないことを検証することよりも
+<p>もちろん、参照が参照先のスコープから逃げ出していないことを検証することよりも
 所有権に関する Rust の話はもっともっと複雑です。
-ポインタがつねに有効であることを証明するのは、もっともっと複雑だからです。
+ポインタが常に有効であることを証明するのは、もっともっと複雑だからです。
 例えばこのコードを見てみましょう。</p>
 <pre><code class="language-rust ignore">let mut data = vec![1, 2, 3];
-// 内部データのリファレンスを取る
+// 内部データの参照を取る
 let x = &amp;data[0];
 
 // しまった! `push` によって `data` の格納先が再割り当てされてしまった。
@@ -241,7 +241,7 @@ <h1><a class="header" href="#所有権とライフタイム" id="所有権とラ
 <p>単純なスコープ解析では、このバグは防げません。
 <code>data</code> のライフタイムは十分に長いからです。
 問題は、その参照を保持している間に、参照先が<em>変わって</em>しまったことです。
-Rust でリファレンスを取ると、参照先とその所有者がフリーズされるのは、こういう理由なのです。</p>
+Rust で参照を取ると、参照先とその所有者がフリーズされるのは、こういう理由なのです。</p>
 
                     </main>