Fix repr-rust.md (#16)

* Fix sentence to make it natural

* Translate "bits"

It is not syntax word and translating it does not lose readability.

* Fix typo

* null -> ヌル

* Translate "bit"

Author: toku-sa-n

src/repr-rust.md

@@ -11,15 +11,15 @@ platform-specific behavior. In particular, on x86 `u64` and `f64` may be only
 aligned to 32 bits.
 -->
 
-最初に重要なことは、すべての型はバイト単位で指定されたアラインメントに従います。
+最初に重要なこととして、すべての型はバイト単位で指定されたアラインメントに従います。
 ある型のアラインメントは、値を格納する有効なアドレスを規定します。
 アラインメント `n` の値は、`n` の倍数のアドレスにのみ格納できます。
 つまりアラインメント 2 は、偶数アドレスにのみ格納できることを意味し、
 アラインメント 1 はどこにでも格納できることになります。
 アラインメントの最小値は 1 で、常に 2 のべき乗になります。
 ほとんどのプリミティブ型はそのサイズにアラインメントされますが、
 これはプラットフォーム依存の挙動です。
-特に x86 では `u64` と `f64` は 32 bits にアラインされるかもしれません。
+特に x86 では `u64` と `f64` は 32ビットにアラインされるかもしれません。
 
 <!--
 A type's size must always be a multiple of its alignment. This ensures that an
@@ -84,7 +84,7 @@ of 32-bits. It will potentially become:
 -->
 
 この構造体は、メンバーのプリミティブ型が対応するサイズにアラインされるアーキテクチャでは、
-32-bit にアラインされます。そのため全体の構造体のサイズも 32 bit の倍数になります。
+32ビットにアラインされます。そのため全体の構造体のサイズも 32ビットの倍数になります。
 このようになるでしょう。
 
 ```rust
@@ -93,7 +93,7 @@ struct A {
     _pad1: [u8; 3], // `b` のアラインメントのため
     b: u32,
     c: u16,
-    _pad2: [u8; 2], // 全体のサイズを 4 byte の倍数にするため
+    _pad2: [u8; 2], // 全体のサイズを 4バイトの倍数にするため
 }
 ```
 
@@ -137,7 +137,7 @@ features of Rust make it desirable for the language to play with data layout in
 complex ways.
 -->
 
-この A, B の例では、レイアウトのが保証されないなんて融通が利かないと思うかもしれませんが、
+この A, B の例では、レイアウトが保証されないなんて融通が利かないと思うかもしれませんが、
 他の機能を考えると、Rust がデータレイアウトを複雑にいじくれるようにするのは好ましいのです。
 
 <!--
@@ -242,8 +242,8 @@ size_of::<&T>()`.
 -->
 
 ところが、このような表現が非効率な場合もあります。
-わかりやすい例としては、Rust の "null ポインタ最適化" があります。
-これは、ある enum がデータを持たないメンバー（たとえば `None`）と、（ネストしてるかもしれない）null を取らないメンバー（たとえば `&T`）から構成される場合、null ポインタをデータを持たないメンバーと解釈することができるので、タグが不要になります。
+わかりやすい例としては、Rust の "ヌルポインタ最適化" があります。
+これは、ある enum がデータを持たないメンバー（たとえば `None`）と、（ネストしてるかもしれない）ヌルを取らないメンバー（たとえば `&T`）から構成される場合、ヌルポインタをデータを持たないメンバーと解釈することができるので、タグが不要になります。
 その結果、たとえば `size_of::<Optiona<&T>>() == size_of::<&T>()` となります。
 
 <!--
@@ -256,12 +256,12 @@ special constrained representations. As such it is *especially* desirable that
 we leave enum layout unspecified today.
 -->
 
-Rust には、null ポインタになりえない型や、null ポインタを含まない型がたくさんあります。
+Rust には、ヌルポインタになりえない型や、ヌルポインタを含まない型がたくさんあります。
 例えば `Box<T>`, `Vec<T>`, `String`, `&T`, `&mut T` などです。
 同様に、ネストした複数の enum が、タグを単一の判別子に押し込めることも考えられます。
 タグが取り得る値は、定義により限られているからです。
 原理的には、enum はとても複雑なアルゴリズムを使って、ネストした型を特別な制約のもとで表現し、
-bit を隠すことができるでしょう。
+ビットを隠すことができるでしょう。
 このため、enum のレイアウトを規定しないでおくことは、現状では *特に* 好ましいのです。