From 7535ea782b21f37d17ca752115cfb2c6105516d6 Mon Sep 17 00:00:00 2001
From: Jesse <35264598+JesseAtSZ@users.noreply.github.com>
Date: Tue, 11 Jan 2022 20:51:11 +0800
Subject: [PATCH] Update enum.md

---
 book/contents/basic/compound-type/enum.md | 28 +++++++++++------------
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/book/contents/basic/compound-type/enum.md b/book/contents/basic/compound-type/enum.md
index 20668925..723801e5 100644
--- a/book/contents/basic/compound-type/enum.md
+++ b/book/contents/basic/compound-type/enum.md
@@ -1,6 +1,6 @@
 # 枚举
 
-枚举(enum或enumeration)允许你通过列举可能的成员来定义一个**枚举类型**,例如扑克牌花色：
+枚举(enum或enumeration)允许你通过列举可能的取值来定义一个**枚举类型**，例如扑克牌花色：
 ```rust
 enum PokerSuit {
   Clubs,
@@ -14,7 +14,7 @@ enum PokerSuit {
 
 再回到之前创建的`PokerSuit`，扑克总共有四种花色，而这里我们枚举出所有的可能值，这也正是`枚举`名称的由来。
 
-任何一张扑克，它的花色肯定会落在四种花色中，而且也只会落在其中一个花色上，这种特性非常适合枚举的使用，因为**枚举值**只可能是其中一个成员。抽象来看，四种花色尽管是不同的花色，但是它们都是扑克花色这个概念，因此当某个函数处理扑克花色时，可以把它们当作相同的类型进行传参。
+任何一张扑克，它的花色肯定会落在四种花色中，而且也只会落在其中一个花色上，这种特性非常适合枚举的使用，因为**枚举值**只可能是其中某一个成员。抽象来看，四种花色尽管是不同的花色，但是它们都是扑克花色这个概念，因此当某个函数处理扑克花色时，可以为花色定义一种类型来作为入参。
 
 细心的读者应该注意到，我们对之前的`枚举类型`和`枚举值`进行了重点标注，这是因为对于新人来说容易混淆相应的概念，总而言之：
 **枚举类型是一个类型，它会包含所有可能的枚举成员, 而枚举值是该类型中的具体某个成员的实例。**
@@ -43,7 +43,7 @@ fn print_suit(card: PokerSuit) {
 
 `print_suit`函数的参数类型是`PokerSuit`，因此我们可以把`heart`和`diamond`传给它，虽然`heart`是基于`PokerSuit`下的`Hearts`成员实例化的，但是它是货真价实的`PokerSuit`枚举类型。
 
-接下来，我们想给扑克牌变得更加实用，那么需要给每张牌赋予一个值：`A`(1)-`K`(13)，这样再加上花色，就是一张真实的扑克牌了，例如红心A。
+接下来，每张扑克牌除了花色，还有数值。我们想让扑克牌变得更加实用，那么需要给每张牌赋予一个值：`A`(1)-`K`(13)，这样就是一张真实的扑克牌了，例如红心A。
 
 目前来说，枚举值还不能带有值，因此先用结构体来实现：
 ```rust
@@ -70,9 +70,9 @@ fn main() {
    };
 }
 ```
-这段代码很好的完成了它的使命，通过结构体`PokerCard`来代表一张牌，结构体的`suit`字段表示牌的花色，类型是`PokerSuit`枚举类型，`value`字段代表扑克牌的值。
+这段代码很好的完成了它的使命，通过结构体`PokerCard`来代表一张牌，结构体的`suit`字段表示牌的花色，类型是`PokerSuit`枚举类型，`value`字段代表扑克牌的数值。
 
-可以吗？可以！好吗？说实话，不咋地，因为还有简洁的多的方式来实现：
+可以吗？可以！好吗？说实话，不咋地，因为还有简洁得多的方式来实现：
 ```rust
 enum PokerCard {
     Clubs(u8),
@@ -87,9 +87,9 @@ fn main() {
 }
 ```
 
-直接将数据信息关联到枚举成员上，直接省去近一半的代码，这种实现漂亮不？
+直接将数据信息关联到枚举成员上，省去近一半的代码，这种实现是不是更漂亮？
 
-而且不仅仅如此，同一个枚举类型下的不同成员还能持有不同的类型，例如让部分花色打印`1-13`的字样，另外花色打印上`A-K`的字样:
+不仅如此，同一个枚举类型下的不同成员还能持有不同的数据类型，例如让某些花色打印`1-13`的字样，另外的花色打印上`A-K`的字样:
 ```rust
 enum PokerCard {
     Clubs(u8),
@@ -122,7 +122,7 @@ enum IpAddr {
     V6(Ipv6Addr),
 }
 ```
-该例子跟我们之前的扑克牌很像，只不过枚举成员包含的类型更复杂了，变成了结构体：分别通过`Ipv4Addr`和`Ipv6Addr`来定义两种不同的IP数据。
+这个例子跟我们之前的扑克牌很像，只不过枚举成员包含的类型更复杂了，变成了结构体：分别通过`Ipv4Addr`和`Ipv6Addr`来定义两种不同的IP数据。
 
 从这些例子可以看出，**任何类型的数据都可以放入枚举成员中**: 例如字符串、数值、结构体甚至另一个枚举。
 
@@ -159,7 +159,7 @@ struct WriteMessage(String); // 元组结构体
 struct ChangeColorMessage(i32, i32, i32); // 元组结构体
 ```
 
-由于每个结构体都有自己的类型，因此我们无法在需要同一类型的地方进行使用，例如某个函数它的功能是接受消息并进行发送，那么用枚举的方式，就可以接收不同的消息，但是用结构体，该函数无法接受4个不同的结构体作为参数。
+由于每个结构体都有自己的类型，采用结构体的方式定义这些消息相当于声明了四个结构体，如果一个函数只允许传入一个类型的变量，这样显然是不合适的，例如某个函数它的功能是接受消息并进行发送，那么用枚举的方式，只需要一种枚举类型就可以接收不同的消息，但是如果用结构体，该函数需要接受4个不同的结构体作为参数，这样就复杂了很多。
 
 而且从代码规范角度来看，枚举的实现更简洁，代码内聚性更强，不像结构体的实现，分散在各个地方。
 
@@ -209,7 +209,7 @@ enum Option<T> {
 
 其中`T`是泛型参数，`Some(T)`表示该枚举成员的数据类型是`T`, 换句话说，`Some`可以包含任何类型的数据。
 
-`Option<T>` 枚举是如此有用以至于它甚至被包含在了`prelude`(Rust会将最常用的类型、函数等提前引入进来，避免我们再手动引入)之中，你不需要将其显式引入作用域。另外，它的成员也是如此，无需使用`Option::`前缀就可直接使用`Some` 和 `None`。总之，不能因为`Some(T)`和`None`中没有`Option::`的身影，就否认它们是`Option`下的卧龙凤雏。
+`Option<T>` 枚举是如此有用以至于它甚至被包含在了`prelude`(属于Rust标准库，Rust会将最常用的类型、函数等提前引入进来，避免我们再手动引入)之中，你不需要将其显式引入作用域。另外，它的成员也是如此，无需使用`Option::`前缀就可直接使用`Some` 和 `None`。总之，不能因为`Some(T)`和`None`中没有`Option::`的身影，就否认它们是`Option`下的卧龙凤雏。
 
 再来看以下代码：
 ```rust
@@ -222,7 +222,7 @@ let absent_number: Option<i32> = None;
 
 如果使用 `None` 而不是 `Some`，需要告诉 Rust `Option<T>` 是什么类型的，因为编译器只通过 `None` 值无法推断出 `Some` 成员保存的值的类型。
 
-当有一个 `Some` 值时，我们就知道存在一个值，而这个值保存在 `Some` 中。当有个 `None` 值时，在某种意义上，它跟空值具有相同的意义：并没有一个有效的值。那么，`Option<T>` 为什么就比空值要好呢？
+当有一个 `Some` 值时，我们就知道存在一个值，而这个值保存在 `Some` 中。当有个 `None` 值时，在某种意义上，它跟空值具有相同的意义：没有一个有效的值。那么，`Option<T>` 为什么就比空值要好呢？
 
 简而言之，因为 `Option<T>` 和 `T`（这里 `T` 可以是任何类型）是不同的类型，例如，这段代码不能编译，因为它尝试将 `Option<i8>`(`Option<T>`) 与 `i8`(`T`) 相加：
 
@@ -245,9 +245,9 @@ not satisfied
   |
 ```
 
-很好！事实上，错误信息意味着 Rust 不知道该如何将 `Option<i8>` 与 `i8` 相加，因为它们的类型不同。当在 Rust 中拥有一个像 `i8` 这样类型的值时，编译器确保它总是有一个有效的值。我们可以自信使用而无需做空值检查。只有当使用 `Option<i8>`（或者任何用到的类型）的时候需要担心可能没有值，而编译器会确保我们在使用值之前处理了为空的情况。
+很好！事实上，错误信息意味着 Rust 不知道该如何将 `Option<i8>` 与 `i8` 相加，因为它们的类型不同。当在 Rust 中拥有一个像 `i8` 这样类型的值时，编译器确保它总是有一个有效的值，我们可以自信使用而无需做空值检查。只有当使用 `Option<i8>`（或者任何用到的类型）的时候才需要担心可能没有值，而编译器会确保我们在使用值之前处理了为空的情况。
 
-换句话说，在对 `Option<T>` 进行 `T` 的运算之前必须将其转换为 `T`。通常这能帮助我们捕获到空值最常见的问题之一：假设某值不为空但实际上为空的情况。
+换句话说，在对 `Option<T>` 进行 `T` 的运算之前必须将其转换为 `T`。通常这能帮助我们捕获到空值最常见的问题之一：期望某值不为空但实际上为空的情况。
 
 不再担心会错误的使用一个空值，会让你对代码更加有信心。为了拥有一个可能为空的值，你必须要显式的将其放入对应类型的 `Option<T>` 中。接着，当使用这个值时，必须明确的处理值为空的情况。只要一个值不是 `Option<T>` 类型，你就 **可以** 安全的认定它的值不为空。这是 Rust 的一个经过深思熟虑的设计决策，来限制空值的泛滥以增加 Rust 代码的安全性。
 
@@ -271,4 +271,4 @@ let six = plus_one(five);
 let none = plus_one(None);
 ```
 
-`plus_one`通过`match`来处理不同`Option`的情况。
\ No newline at end of file
+`plus_one`通过`match`来处理不同`Option`的情况。