高阶内容

可以通过 unsafe 关键字来切换到不安全 Rust，接着可以开启一个新的存放不安全代码的块。这里有几类可以在不安全 Rust 中进行而不能用于安全 Rust 的操作，它们称之为 “不安全的超级力量。” 这些超级力量是：

1. 解引用裸指针
2. 调用不安全的函数或方法
3. 访问或修改可变静态变量
4. 实现不安全 trait

有一点很重要，unsafe 并不会关闭 借用检查器 或禁用任何 其他 Rust 安全检查 ：如果在不安全代码中使用引用，它仍会被检查

unsafe 关键字只是提供了那几个不会被编译器检查内存安全的功能

仍然能在不安全块中获得某种程度的安全

再者，unsafe 不意味着块中的代码就一定是危险的或者必然导致内存安全问题：其意图在于作为程序员将会确保 unsafe 块中的代码以有效的方式访问内存

     人是会犯错误的，错误总会发生

     不过通过要求这类操作必须位于标记为 unsafe 的块中，就能够知道任何与内存安全相关的错误必定位于 unsafe 块内

     保持 unsafe 块尽可能小，如此当之后调查内存 bug 时就会感谢你自己了

为了尽可能隔离不安全代码，将 不安全代码 封装 进一个 安全的抽象 并 提供 安全 API 是一个好主意

     标准库的一部分被实现为在被评审过的不安全代码之上的安全抽象

     这个技术防止了 unsafe 泄露到所有你或者用户希望使用由 unsafe 代码实现的功能的地方，因为使用其安全抽象是安全的

接下来按顺序依次介绍上述几个超级力量，同时会看到一些提供不安全代码的安全接口的抽象

   回到前面的 “悬垂引用” 部分，那里提到了编译器会确保引用总是有效的

不安全 Rust 有两个被称为 裸指针 的类似于引用的新类型。和引用一样，裸指针是 可变 或 不可变 的，分别写作 *const T 和 *mut T

• 这里的 星号 不是解引用运算符；它是 类型名称 的一部分
• 在裸指针的上下文中，不可变意味着 指针解引用 之后 不能直接 赋值

与引用和智能指针的区别在于，记住裸指针：

• 允许忽略借用规则，可以同时拥有不可变和可变的指针，或多个指向相同位置的可变指针
• 不保证指向有效的内存
• 允许为空
• 不能实现任何自动清理功能

   通过去掉 Rust 强加的保证，可以放弃安全保证以换取性能或使用另一个语言或硬件接口的能力，此时 Rust 的保证并不适用

下面展示了如何从引用同时创建不可变和可变裸指针：

let mut num = 5;

let r1 = &num as *const i32;
let r2 = &mut num as *mut i32;

注意：这里没有引入 unsafe 关键字。可以在 安全代码 中 创建 裸指针，只是 不能 在 不安全块之外 解引用 裸指针

     这里使用 as 将不可变和可变引用强转为对应的裸指针类型

     因为直接从保证安全的引用来创建他们，可以知道这些特定的裸指针是有效，但是不能对任何裸指针做出如此假设

接下来创建一个不能确定其有效性的裸指针，下面展示了如何创建一个指向任意内存地址的裸指针

let address = 0x012345usize;
let r = address as *const i32;

     尝试使用任意内存是未定义行为：此地址可能有数据也可能没有，编译器可能会优化掉这个内存访问，或者程序可能会出现段错误

     通常没有好的理由编写这样的代码，不过却是可行的

对裸指针使用解引用运算符 *，这需要一个 unsafe 块：

let mut num = 5;

let r1 = &num as *const i32;
let r2 = &mut num as *mut i32;

unsafe {
    println!("r1 is: {}", *r1);
    println!("r2 is: {}", *r2);
}

     创建一个指针不会造成任何危险；只有当访问其指向的值时才有可能遇到无效的值

示例创建了同时指向相同内存位置 num 的裸指针 *const i32 和 *mut i32

• 如果尝试创建 num 的不可变和可变引用，这将无法编译因为 Rust 的所有权规则不允许拥有可变引用的同时拥有不可变引用
• 通过裸指针，就能够同时创建同一地址的可变指针和不可变指针
• 若通过 可变指针 修改 数据，则可能造成 数据竞争

     既然存在这么多的危险，为何还要使用裸指针呢？

     一个主要的应用场景便是调用 C 代码接口

     另一个场景是构建借用检查器无法理解的安全抽象

不安全函数和方法与常规函数方法十分类似，除了其开头有一个额外的 unsafe

     在此上下文中，关键字unsafe表示该函数具有调用时需要满足的要求，而 Rust 不会保证满足这些要求

     通过在 unsafe 块中调用不安全函数，表明已经阅读过此函数的文档并对其是否满足函数自身的契约负责

如下是一个没有做任何操作的不安全函数 dangerous 的例子：

unsafe fn dangerous() {}

unsafe {
    dangerous();
}

必须在一个单独的 unsafe 块中调用 dangerous 函数。如果尝试不使用 unsafe 块调用 dangerous，则会得到一个错误：

error[E0133]: call to unsafe function requires unsafe function or block
 -->
  |
4 |     dangerous();
  |     ^^^^^^^^^^^ call to unsafe function

     通过将 dangerous 调用插入 unsafe 块中，就向 Rust 保证了已经阅读过函数的文档，理解如何正确使用，并验证过其满足函数的契约

不安全函数体也是有效的 unsafe 块，所以在不安全函数中进行另一个不安全操作时无需新增额外的 unsafe 块

     目前为止都尽量避免讨论 全局变量，Rust 确实支持他们，不过这对于 Rust 的所有权规则来说是有问题的

     如果有两个线程访问相同的可变全局变量，则可能会造成数据竞争

全局变量在 Rust 中被称为 静态 (static)变量。下面展示了一个拥有字符串 slice 值的静态变量的声明和应用：

static HELLO_WORLD: &str = "Hello, world!";

fn main() {
    println!("name is: {}", HELLO_WORLD);
}

static 变量类似于开头讨论的常量。通常静态变量的名称采用 SCREAMING_SNAKE_CASE 写法，并 必须 标注 变量的类型 ，在这个例子中是 &'static str：

• 静态变量只能储存拥有 'static 生命周期的引用 ，这意味着 Rust 编译器可以自己计算出其生命周期而无需显式标注
• 访问 不可变 静态变量是 安全 的

常量与不可变静态变量可能看起来很类似，不过一个微妙的区别是：

• 静态变量 中的值有一个 固定的内存地址 ，使用这个值总是会访问相同的地址
• 常量 则允许在任何被用到的时候 复制 其 数据

常量与静态变量的另一个区别在于 静态变量 可以是 可变 的。 访问 和 修改 可变 静态变量 都是 不安全 的。下面展示了如何声明、访问和修改名为 COUNTER 的可变静态变量：

static mut COUNTER: u32 = 0;

fn add_to_count(inc: u32) {
    unsafe {
        COUNTER += inc;
    }
}

fn main() {
    add_to_count(3);

    unsafe {
        println!("COUNTER: {}", COUNTER);
    }
}

就像常规变量一样，使用 mut 关键来指定可变性。任何读写 COUNTER 的代码都必须位于 unsafe 块中。这段代码可以编译并如期打印出 COUNTER: 3，因为这是单线程的。拥有多个线程访问 COUNTER 则可能导致数据竞争

     拥有可以全局访问的可变数据，难以保证不存在数据竞争，这就是为何 Rust 认为可变静态变量是不安全的

     任何可能的情况，请优先使用并发技术和线程安全智能指针，这样编译器就能检测不同线程间的数据访问是否是安全的

最后一个只能用在 unsafe 中的操作是实现不安全 trait。当至少有一个方法中包含编译器不能验证的不变量时 trait 是不安全的。可以在 trait 之前增加 unsafe 关键字将 trait 声明为 unsafe，同时 trait 的实现也必须标记为 unsafe：

unsafe trait Foo {
    // methods go here
}

unsafe impl Foo for i32 {
    // method implementations go here
}

通过 unsafe impl，将保证编译器所不能验证的不变量

作为一个例子，回忆“使用 Sync 和 Send trait 的可扩展并发” 部分中的 Sync 和 Send 标记 trait，编译器会自动为完全由 Send 和 Sync 类型组成的类型自动实现他们

如果实现了一个包含一些不是 Send 或 Sync 的类型，比如裸指针，并希望将此类型标记为 Send 或 Sync，则必须使用 unsafe

Rust 不能验证我们的类型保证可以安全的跨线程发送或在多线程键访问，所以需要我们自己进行检查并通过 unsafe 表明

使用 unsafe 来进行这四个操作（超级力量）之一是没有问题的，甚至是不需要深思熟虑的

     不过使用 unsafe 代码正确也实属不易，因为编译器不能帮助保证内存安全

     当有理由使用 unsafe 代码时，是可以这么做的，通过使用显式的 unsafe 标注使得在出现错误时易于追踪问题的源头

关联类型 是一个将 类型占位符 与 trait 相关联的方式，这样 trait 的方法签名中就可以使用这些占位符类型。trait 的实现者会针对特定的实现在这个类型的位置指定相应的具体类型。如此可以定义一个使用多种类型的 trait，直到实现此 trait 时都无需知道这些类型具体是什么

     本章所描述的大部分内容都非常少见

     关联类型则比较适中；它们比本书其他的内容要少见，不过比本章中的很多内容要更常见

一个带有关联类型的 trait 的例子是标准库提供的 Iterator trait。它有一个叫做 Item 的关联类型来替代遍历的值的类型：

pub trait Iterator {
    type Item;

    fn next(&mut self) -> Option<Self::Item>;
}

Item 是一个占位类型，同时 next 方法定义表明它返回 Option<Self::Item> 类型的值。这个 trait 的实现者会指定 Item 的具体类型，然而不管实现者指定何种类型, next 方法都会返回一个包含了此具体类型值的 Option

     关联类型看起来像一个类似泛型的概念，因为它允许定义一个函数而不指定其可以处理的类型

     那么为什么要使用关联类型呢？

通过一个前面出现过的 Counter 结构体上实现 Iterator trait 的例子来检视其中的区别。下面指定了 Item 的类型为 u32：

impl Iterator for Counter {
    type Item = u32;

    fn next(&mut self) -> Option<Self::Item> {
        // --snip--

这类似于泛型。那么为什么 Iterator trait 不像下面那样定义呢？

pub trait Iterator<T> {
    fn next(&mut self) -> Option<T>;
}

     区别在于当如上面那样使用泛型时，则不得不在每一个实现中标注类型，这是因为我们也可以实现为 Iterator<String> for Counter，或任何其他类型，这样就可以有多个 Counter 的 Iterator 的实现

     换句话说，当 trait 有泛型参数时，可以多次实现这个 trait，每次需改变泛型参数的具体类型，接着当使用 Counter 的 next 方法时，必须提供类型注解来表明希望使用 Iterator 的哪一个实现

通过关联类型，则无需标注类型因为不能多次实现这个 trait。对于使用关联类型的定义，只能选择一次 Item 会是什么类型，因为只能有一个 impl Iterator for Counter。当调用 Counter 的 next 时不必每次指定需要 u32 值的迭代器

当使用泛型类型参数时，可以为泛型指定一个默认的具体类型。如果默认类型就足够的话，这消除了为具体类型实现 trait 的需要。为泛型类型指定默认类型的语法是在声明泛型类型时使用 <PlaceholderType=ConcreteType>

这种情况的一个非常好的例子是用于运算符重载，运算符重载：是指在特定情况下自定义运算符（比如 +）行为的操作

Rust 并不允许创建自定义运算符或重载任意运算符，不过 std::ops 中所列出的运算符和相应的 trait 可以通过实现运算符相关 trait 来重载

例如，下面展示了如何在 Point 结构体 上实现 Add trait 来 重载 + 运算符 ，这样就可以将两个 Point 实例相加了：

use std::ops::Add;

#[derive(Debug, PartialEq)]
struct Point {
    x: i32,
    y: i32,
}

impl Add for Point {
    type Output = Point;

    fn add(self, other: Point) -> Point {
        Point {
            x: self.x + other.x,
            y: self.y + other.y,
        }
    }
}

fn main() {
    assert_eq!(Point { x: 1, y: 0 } + Point { x: 2, y: 3 },
               Point { x: 3, y: 3 });
}

add 方法将两个 Point 实例的 x 值和 y 值分别相加来创建一个新的 Point。 Add trait 有一个叫做 Output 的 关联类型 ，它用来决定 add 方法的返回值类型，这里默认泛型类型位于 Add trait 中。这里是其定义：

trait Add<RHS=Self> {
    type Output;

    fn add(self, rhs: RHS) -> Self::Output;
}

这看来应该很熟悉，这是一个带有一个方法和一个关联类型的 trait。比较陌生的部分是尖括号中的 RHS=Self ：这个语法叫做 默认类型参数 。RHS 是一个泛型类型参数，它用于定义 add 方法中的 rhs 参数

     如果实现 Add trait 时不指定 RHS 的具体类型，RHS 的类型将是默认的 Self 类型，也就是在其上实现 Add 的类型

     当为 Point 实现 Add 时，使用了默认的 RHS，因为希望将两个 Point 实例相加

看看一个实现 Add trait 时希望自定义 RHS 类型而不是使用默认类型的例子。这里有两个存放不同单元值的结构体，Millimeters 和 Meters。希望能够将毫米值与米值相加，并让 Add 的实现正确处理转换。可以为 Millimeters 实现 Add 并以 Meters 作为 RHS：

use std::ops::Add;

struct Millimeters(u32);
struct Meters(u32);

impl Add<Meters> for Millimeters {
    type Output = Millimeters;

    fn add(self, other: Meters) -> Millimeters {
        Millimeters(self.0 + (other.0 * 1000))
    }
}

     为了使 Millimeters 和 Meters 能够相加，指定 impl Add<Meters> 来设定 RHS 类型参数的值而不是使用默认的 Self

默认参数类型主要用于如下两个方面：

1. 扩展类型而不破坏现有代码
2. 在大部分用户都不需要的特定情况进行自定义

     标准库的 Add trait 就是第二个目的：大部分时候你会将两个相似的类型相加，不过它提供了自定义额外行为的能力。在 Add trait 定义中使用默认类型参数意味着大部分时候无需指定额外的参数。换句话说，一小部分实现的样板代码是不必要的，这样使用 trait 就更容易了

     第一个目的是相似的，但过程是反过来的：如果需要为现有 trait 增加类型参数，为其提供一个默认类型将允许在不破坏现有实现代码的基础上扩展 trait 的功能

Rust 既不能避免一个 trait 与另一个 trait 拥有相同名称的方法，也不能阻止为同一类型同时实现这两个 trait

甚至直接在类型上实现开始已经有的同名方法也是可能的！

不过，当调用这些同名方法时，需要告诉 Rust 希望使用哪一个。下面定义了 trait Pilot 和 Wizard 都拥有方法 fly。接着在一个本身已经实现了名为 fly 方法的类型 Human 上实现这两个 trait。每一个 fly 方法都进行了不同的操作：

trait Pilot {
    fn fly(&self);
}

trait Wizard {
    fn fly(&self);
}

struct Human;

impl Pilot for Human {
    fn fly(&self) {
        println!("This is your captain speaking.");
    }
}

impl Wizard for Human {
    fn fly(&self) {
        println!("Up!");
    }
}

impl Human {
    fn fly(&self) {
        println!("*waving arms furiously*");
    }
}

当调用 Human 实例的 fly 时，编译器默认调用直接是现在类型上的方法：

fn main() {
    let person = Human;
    person.fly();
}

   运行这段代码会打印出 *waving arms furiously*，这表明 Rust 调用了直接实现在 Human 上的 fly 方法

为了能够调用 Pilot trait 或 Wizard trait 的 fly 方法，需要使用更明显的语法以便能指定指的是哪个 fly 方法：

fn main() {
    let person = Human;
    Pilot::fly(&person);
    Wizard::fly(&person);
    person.fly();
}

在方法名前指定 trait 名向 Rust 澄清了希望调用哪个 fly 实现。也可以选择写成 Human::fly(&person)，这等同于示例 19-18 中的 person.fly()，不过如果无需消歧义的话这么写就有点长了。运行这段代码会打印出：

This is your captain speaking.
Up!
*waving arms furiously*

   因为 fly 方法获取一个 self 参数，如果有两个 类型 都实现了同一 trait，Rust 可以根据 self 的类型计算出应该使用哪一个 trait 实现

然而，关联函数是 trait 的一部分，但没有 self 参数。当同一作用域的两个类型实现了同一 trait，Rust 就不能计算出期望的是哪一个类型，除非使用 完全限定语法 。例如，下面的 Animal trait 来说，它有关联函数 baby_name，结构体 Dog 实现了 Animal，同时有关联函数 baby_name 直接定义于 Dog 之上：

trait Animal {
    fn baby_name() -> String;
}

struct Dog;

impl Dog {
    fn baby_name() -> String {
        String::from("Spot")
    }
}

impl Animal for Dog {
    fn baby_name() -> String {
        String::from("puppy")
    }
}

fn main() {
    println!("A baby dog is called a {}", Dog::baby_name());
}

这段代码用于一个动物收容所，他们将所有的小狗起名为 Spot，这实现为定义于 Dog 之上的关联函数 baby_name

Dog 类型还实现了 Animal trait，它描述了所有动物的共有的特征。小狗被称为 puppy，这表现为 Dog 的 Animal trait 实现中与 Animal trait 相关联的函数 baby_name

在 main 调用了 Dog::baby_name 函数，它直接调用了定义于 Dog 之上的关联函数。这段代码会打印出：

A baby dog is called a Spot

这并不是我们需要的。希望调用的是 Dog 上 Animal trait 实现那部分的 baby_name 函数，这样能够打印出 A baby dog is called a puppy。前面用到的技术在这并不管用：

fn main() {
    println!("A baby dog is called a {}", Animal::baby_name());
}

会得到一个编译错误：

error[E0283]: type annotations required: cannot resolve `_: Animal`
  --> src/main.rs:20:43
   |
20 |     println!("A baby dog is called a {}", Animal::baby_name());
   |                                           ^^^^^^^^^^^^^^^^^
   |
   = note: required by `Animal::baby_name`

     因为 Animal::baby_name 是关联函数而不是方法，因此它没有 self 参数，Rust 无法计算出所需的是哪一个 Animal::baby_name 实现

为了消歧义并告诉 Rust 希望使用的是 Dog 的 Animal 实现，需要使用 完全限定语法 ，这是调用函数时最为明确的方式：

fn main() {
    println!("A baby dog is called a {}", <Dog as Animal>::baby_name());
}

在尖括号中向 Rust 提供了类型注解，并通过在此函数调用中将 Dog 类型当作 Animal 对待，来指定希望调用的是 Dog 上 Animal trait 实现中的 baby_name 函数。现在这段代码会打印出期望的数据：

A baby dog is called a puppy

通常，完全限定语法定义为：

<Type as Trait>::function(receiver_if_method, next_arg, ...);

对于关联函数，其没有一个 receiver，故只会有其他参数的列表

     可以选择在任何函数或方法调用处使用完全限定语法。然而，允许省略任何 Rust 能够从程序中的其他信息中计算出的部分

     只有当存在多个同名实现而 Rust 需要帮助以便知道我们希望调用哪个实现时，才需要使用这个较为冗长的语法

     有时可能会需要某个 trait 使用另一个 trait 的功能。在这种情况下，需要能够依赖相关的 trait 也被实现

     这个所需的 trait 是实现的 trait 的 父 trait(supertrait)

例如希望创建一个带有 outline_print 方法的 trait OutlinePrint，它会打印出带有星号框的值。也就是说，如果 Point 实现了 Display 并返回 (x, y)，调用以 1 作为 x 和 3 作为 y 的 Point 实例的 outline_print 会显示如下：

**********
*        *
* (1, 3) *
*        *
**********

在 outline_print 的实现中，因为希望能够使用 Display trait 的功能，则需要说明 OutlinePrint 只能用于同时也实现了 Display 并提供了 OutlinePrint 需要的功能的类型。可以通过在 trait 定义中指定 OutlinePrint: Display 来做到这一点。这类似于为 trait 增加 trait bound。下面示例展示了一个 OutlinePrint trait 的实现：

use std::fmt;

trait OutlinePrint: fmt::Display {
    fn outline_print(&self) {
        let output = self.to_string();
        let len = output.len();
        println!("{}", "*".repeat(len + 4));
        println!("*{}*", " ".repeat(len + 2));
        println!("* {} *", output);
        println!("*{}*", " ".repeat(len + 2));
        println!("{}", "*".repeat(len + 4));
    }
}

     因为指定了 OutlinePrint 需要 Display trait，则可以在 outline_print 中使用 to_string， 其会为任何实现 Display 的类型自动实现

     如果不在 trait 名后增加 : Display 并尝试在 outline_print 中使用 to_string，则会得到一个错误说在当前作用域中没有找到用于 &Self 类型的方法 to_string

如果尝试在一个没有实现 Display 的类型上实现 OutlinePrint ：

struct Point {
    x: i32,
    y: i32,
}

impl OutlinePrint for Point {}

一旦在 Point 上实现 Display 并满足 OutlinePrint 要求的限制，比如这样：

use std::fmt;

impl fmt::Display for Point {
    fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {
        write!(f, "({}, {})", self.x, self.y)
    }
}

那么在 Point 上实现 OutlinePrint trait 将能成功编译，并可以在 Point 实例上调用 outline_print 来显示位于星号框中的点的值：

fn main() {
    let point = Point { x: 1, y: 3 };
    point.outline_print();
}

前面“为类型实现 trait” 部分，提到了孤儿规则，它说明只要 trait 或类型对于当前 crate 是本地的话就可以在此类型上实现该 trait

一个绕开这个限制的方法是使用 newtype 模式，它涉及到在一个元组结构体，中创建一个新类型。这个元组结构体带有一个字段作为希望实现 trait 的类型的简单封装。接着这个封装类型对于 crate 是本地的，这样就可以在这个封装上实现 trait

Newtype 是一个源自Haskell 编程语言的概念，使用这个模式没有运行时性能惩罚，这个封装类型在编译时就被省略了

例如，如果想要在 Vec<T> 上实现 Display，而孤儿规则阻止直接这么做，因为 Display trait 和 Vec<T> 都定义于我们的 crate 之外。可以创建一个包含 Vec<T> 实例的 Wrapper 结构体，接着可以在 Wrapper 上实现 Display 并使用 Vec<T> 的值：

use std::fmt;

struct Wrapper(Vec<String>);

impl fmt::Display for Wrapper {
    fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {
        write!(f, "[{}]", self.0.join(", "))
    }
}

fn main() {
    let w = Wrapper(vec![String::from("hello"), String::from("world")]);
    println!("w = {}", w);
}

Display 的实现使用 self.0 来访问其内部的 Vec<T>，因为 Wrapper 是元组结构体而 Vec<T> 是结构体总位于索引 0 的项，接着就可以使用 Wrapper 中 Display 的功能了

     因为 Wrapper 是一个新类型，它没有定义于其值之上的方法；必须直接在 Wrapper 上实现 Vec<T> 的所有方法，这样就可以代理到self.0 上。这允许完全像 Vec<T> 那样对待 Wrapper

     如果希望新类型拥有其内部类型的每一个方法，为封装类型实现 Deref trait，并返回其内部类型是一种解决方案

     如果不希望封装类型拥有所有内部类型的方法，比如为了“限制封装类型的行为”，则必须只自行实现所需的方法

newtype 模式可以用于一些其他还未讨论的功能，包括静态的 确保 某值不被混淆 ，和用来 表示 一个值的单元

     实际上前面中已经有一个这样的例子：Millimeters 和 Meters 结构体都在 newtype 中封装了 u32 值

     如果编写了一个有 Millimeters 类型参数的函数，不小心使用 Meters 或普通的 u32 值来调用该函数的程序是不能编译的

另一个 newtype 模式的应用在于 抽象 掉一些 类型的实现细节

   例如，封装类型可以暴露出与直接使用其内部私有类型时所不同的公有 API，以便限制其功能

newtype 也可以 隐藏 其 内部的泛型类型

例如，可以提供一个封装了 HashMap<i32, String> 的 People 类型，用来储存人名以及相应的 ID

使用 People 的代码只需与提供的公有 API 交互即可，比如向 People 集合增加名字字符串的方法，这样这些代码就无需知道在内部我们将一个 i32 ID 赋予了这个名字了

newtype 模式是一种实现 “封装隐藏了实现细节” 部分所讨论的隐藏实现细节的封装的轻量级方法

连同 newtype 模式，Rust 还提供了声明 类型别名 的能力，使用 type 关键字来给予现有类型另一个名字。例如，可以像这样创建 i32 的别名 Kilometers：

type Kilometers = i32;

这意味着 Kilometers 是 i32 的 同义词 不同于前面创建的 Millimeters 和 Meters 类型。Kilometers 不是一个新的、单独的类型。Kilometers 类型的值将被完全当作 i32 类型值来对待：

type Kilometers = i32;

let x: i32 = 5;
let y: Kilometers = 5;

println!("x + y = {}", x + y);

     因为 Kilometers 是 i32 的别名，他们是同一类型，可以将 i32 与 Kilometers 相加，也可以将 Kilometers 传递给获取 i32 参数的函数

     但通过这种手段无法获得上一部分讨论的 newtype 模式所提供的类型检查的好处

类型别名的主要用途是 减少重复 。例如，可能会有这样很长的类型：

Box<dyn Fn() + Send + 'static>

在函数签名或类型注解中每次都书写这个类型将是枯燥且易于出错的。想象一下全是如此代码的项目：

let f: Box<dyn Fn() + Send + 'static> = Box::new(|| println!("hi"));

fn takes_long_type(f: Box<dyn Fn() + Send + 'static>) {
    // --snip--
}

fn returns_long_type() -> Box<dyn Fn() + Send + 'static> {
    // --snip--
}

类型别名通过减少项目中重复代码的数量来使其更加易于控制。这里为这个冗长的类型引入了一个叫做 Thunk 的别名，这样就可以将所有使用这个类型的地方替换为更短的 Thunk：

type Thunk = Box<dyn Fn() + Send + 'static>;

let f: Thunk = Box::new(|| println!("hi"));

fn takes_long_type(f: Thunk) {
    // --snip--
}

fn returns_long_type() -> Thunk {
    // --snip--
}

     这样就读写起来就容易多了！

     为类型别名选择一个好名字也可以帮助表达意图（单词 thunk 表示会在之后被计算的代码，所以这是一个存放闭包的合适的名字）

类型别名也经常与 Result<T, E> 结合使用来减少重复。考虑一下标准库中的 std::io 模块。I/O 操作通常会返回一个 Result<T, E>，因为这些操作可能会失败。标准库中的 std::io::Error 结构体代表了所有可能的 I/O 错误。std::io 中大部分函数会返回 Result<T, E>，其中 E 是 std::io::Error，比如 Write trait 中的这些函数：

use std::io::Error;
use std::fmt;

pub trait Write {
    fn write(&mut self, buf: &[u8]) -> Result<usize, Error>;
    fn flush(&mut self) -> Result<(), Error>;

    fn write_all(&mut self, buf: &[u8]) -> Result<(), Error>;
    fn write_fmt(&mut self, fmt: fmt::Arguments) -> Result<(), Error>;
}

这里出现了很多的 Result<…, Error>。为此，std::io 有这个类型别名声明：

type Result<T> = std::result::Result<T, std::io::Error>;

因为这位于 std::io 中，可用的完全限定的别名是 std::io::Result<T>。Write trait 中的函数最终看起来像这样：

pub trait Write {
    fn write(&mut self, buf: &[u8]) -> Result<usize>;
    fn flush(&mut self) -> Result<()>;

    fn write_all(&mut self, buf: &[u8]) -> Result<()>;
    fn write_fmt(&mut self, fmt: Arguments) -> Result<()>;
}

类型别名在两个方面有帮助：

1. 易于编写 并 在整个 std::io 中提供了一致的接口
2. 因为这是一个别名，它只是另一个 Result<T, E>，这意味着可以在其上使用 Result<T, E> 的任何方法，以及像 ? 这样的特殊语法

Rust 有一个叫做 ! 的特殊类型。在类型理论术语中，它被称为 empty type，因为它没有值。我们更倾向于称之为 never type 。这个名字描述了它的作用：在 函数从不返回的时候充当返回值 。例如：

fn bar() -> ! {
    // --snip--
}

函数 bar 从不返回，而从不返回的函数被称为 发散函数 。不能创建 ! 类型的值，所以 bar 也不可能返回值。不过一个不能创建值的类型有什么用呢？回想一下以前示例的代码：

let guess: u32 = match guess.trim().parse() {
    Ok(num) => num,
    Err(_) => continue,
};

当时我们忽略了代码中的一些细节。后来学习了 match 的分支必须返回相同的类型。如下代码不能工作：

let guess = match guess.trim().parse() {
    Ok(_) => 5,
    Err(_) => "hello",
}

这里的 guess 必须既是整型 也是 字符串，而 Rust 要求 guess 只能是一个类型

那么 continue 返回了什么呢？为什么开头的示例中会允许一个分支返回 u32 而另一个分支却以 continue 结束呢？

continue 的值是 !。也就是说，当 Rust 要计算 guess 的类型时，它查看这两个分支。前者是 u32 值，而后者是 ! 值。因为 ! 并没有一个值，Rust 决定 guess 的类型是 u32。

描述 ! 的行为的正式方式是 never type 可以强转为任何其他类型。允许 match 的分支以 continue 结束是因为 continue 并不真正返回一个值；相反它把控制权交回上层循环，所以在 Err 的情况，事实上并未对 guess 赋值

never type 的另一个用途是 panic! 。还记得 Option<T> 上的 unwrap 函数吗？它产生一个值或 panic。这里是它的定义：

impl<T> Option<T> {
    pub fn unwrap(self) -> T {
        match self {
            Some(val) => val,
            None => panic!("called `Option::unwrap()` on a `None` value"),
        }
    }
}

这里与前面的 match 发生了相同的情况：

Rust 知道 val 是 T 类型，panic! 是 ! 类型，所以整个 match 表达式的结果是 T 类型。这能工作是因为 panic! 并不产生一个值；它会终止程序

对于 None 的情况，unwrap 并不返回一个值，所以这些代码是有效

最后一个有着 ! 类型的表达式是 loop ：

print!("forever ");

loop {
    print!("and ever ");
}

     这里，循环永远也不结束，所以此表达式的值是 !

     但是如果引入 break 这就不为真了，因为循环在执行到 break 后就会终止

     因为 Rust 需要知道例如应该为特定类型的值分配多少空间

     这样的信息其类型系统的一个特定的角落可能令人迷惑：这就是 动态大小类型的概念

     这有时被称为 “DST” 或 “unsized types”，这些类型允许处理只有在运行时才知道大小的类型

一个贯穿本书都在使用的动态大小类型的细节： str 。没错，不是 &str ，而是 str 本身。str 是一个 DST；直到运行时都不知道字符串有多长。因为直到运行时都不能知道大其小，也就意味着 不能创建 str 类型的变量 ，也 不能获取 str 类型的参数 。考虑一下这些代码，他们不能工作：

let s1: str = "Hello there!";
let s2: str = "How's it going?";

Rust 需要知道应该为特定类型的值分配多少内存，同时所有同一类型的值必须使用相同数量的内存

如果允许编写这样的代码，也就意味着这两个 str 需要占用完全相同大小的空间，不过它们有着不同的长度。这也就是为什么不可能创建一个存放动态大小类型的变量的原因。

那么该怎么办？ 答案是 s1 和 s2 的类型是 &str 而不是 str

所以虽然 &T 是一个储存了 T 所在的内存位置的单个值，&str 则是 两个 值：str 的地址和其长度。这样，&str 就有了一个在编译时可以知道的大小：它是 usize 长度的两倍。也就是说，我们总是知道 &str 的大小，而无论其引用的字符串是多长。这里是 Rust 中动态大小类型的常规用法：他们有一些额外的元信息来储存动态信息的大小。这引出了动态大小类型的黄金规则： 必须将动态大小类型的值置于某种指针之后

     可以将 str 与所有类型的指针结合：比如 Box<str> 或 Rc<str>

     事实上，不过是另一个动态大小类型：trait。每一个 trait 都是一个可以通过 trait 名称来引用的动态大小类型

     在“为使用不同类型的值而设计的 trait 对象” 部分，提到了为了将 trait 用于 trait 对象，必须将他们放入指针之后，比如 &Trait 或 Box<Trait>（Rc<Trait> 也可以）

为了处理 DST，Rust 有一个特定的 trait 来决定一个类型的大小是否在编译时可知：这就是 Sized trait 。这个 trait 自动为编译器在编译时就知道大小的类型实现。另外，Rust 隐式的为每一个泛型函数增加了 Sized bound 。也就是说，对于如下泛型函数定义：

fn generic<T>(t: T) {
    // --snip--
}

实际上被当作如下处理：

fn generic<T: Sized>(t: T) {
    // --snip--
}

泛型函数默认只能用于在编译时已知大小的类型。然而可以使用如下特殊语法来放宽这个限制：

fn generic<T: ?Sized>(t: &T) {
    // --snip--
}

?Sized trait bound 与 Sized 相对；也就是说，它可以解释为 T 可能是也可能不是 Sized 的

     这个语法只能用于 Sized ，而不能用于其他 trait

     另外注意将 t 参数的类型从 T 变为了 &T：因为其类型可能不是 Sized 的，所以需要将其置于某种指针之后，在这个例子中选择了引用。

     前面已经讨论过了如何向函数传递闭包，也可以向函数传递常规函数

     这在希望传递已经定义的函数而不是重新定义闭包作为参数是很有用

通过函数指针允许使用函数作为另一个函数的参数。函数的类型是 fn 被称为 函数指针 。指定参数为函数指针的语法类似于闭包，如下所示：

fn add_one(x: i32) -> i32 {
    x + 1
}

fn do_twice(f: fn(i32) -> i32, arg: i32) -> i32 {
    f(arg) + f(arg)
}

fn main() {
    let answer = do_twice(add_one, 5);

    println!("The answer is: {}", answer);
}

这会打印出 The answer is: 12

do_twice 中的 f 被指定为一个接受一个 i32 参数并返回 i32 的 fn。接着就可以在 do_twice 函数体中调用 f。在 main 中，可以将函数名 add_one 作为第一个参数传递给 do_twice

注意： 不要把 fn 和 Fn 闭包 trait 相混淆！ 不同于闭包，fn 是一个类型而不是一个 trait，所以直接指定 fn 作为参数而不是声明一个带有 Fn 作为 trait bound 的泛型参数

函数指针 实现 了所有三个闭包 trait（ Fn 、 FnMut 和 FnOnce ），所以总是可以在调用期望闭包的函数时传递函数指针作为参数。倾向于编写使用泛型和闭包 trait 的函数，这样它就能接受函数或闭包作为参数

一个只期望接受 fn 而不接受闭包的情况的例子是与不存在闭包的外部代码交互时：

C 语言的函数可以接受函数作为参数，但 C 语言没有闭包

作为一个既可以使用内联定义的闭包又可以使用命名函数的例子，看看一个 map 的应用。使用 map 函数将一个数字 vector 转换为一个字符串 vector，就可以使用闭包，比如这样：

let list_of_numbers = vec![1, 2, 3];
let list_of_strings: Vec<String> = list_of_numbers
    .iter()
    .map(|i| i.to_string())
    .collect();

或者可以将函数作为 map 的参数来代替闭包，像是这样：

let list_of_numbers = vec![1, 2, 3];
let list_of_strings: Vec<String> = list_of_numbers
    .iter()
    .map(ToString::to_string)
    .collect();

     注意：这里必须使用 “高级 trait” 部分讲到的完全限定语法，因为存在多个叫做 to_string 的函数

     这里使用了定义于 ToString trait 的 to_string 函数，标准库为所有实现了 Display 的类型实现了这个 trait

另一个实用的模式暴露了 元组结构体 和元组结构体 枚举成员 的 实现细节 ：

• 这些项使用 () 作为初始化语法，这看起来就像 函数调用 ，同时它们确实被实现为返回由参数构造的实例的函数
• 它们也被称为 实现了闭包 trait 的 函数指针 ，并可以采用类似如下的方式调用：

enum Status {
    Value(u32),
    Stop,
}

let list_of_statuses: Vec<Status> =
    (0u32..20)
    .map(Status::Value)
    .collect();

这里创建了 Status::Value 实例，它通过 map 把0~20范围的每一个 u32 值调用 Status::Value 的初始化函数

     一些人倾向于函数风格，一些人喜欢闭包

     这两种形式最终都会产生同样的代码，所以请使用对你来说更明白的形式吧

     闭包表现为 trait，这意味着不能直接返回闭包

     对于大部分需要返回 trait 的情况，可以使用实现了期望返回的 trait 的具体类型来替代函数的返回值

但是不能直接返回闭包，因为他们没有一个可返回的具体类型。也就是说不允许使用函数指针 fn 作为返回值类型，例如下面这段代码尝试直接返回闭包，它并不能编译：　

fn returns_closure() -> Fn(i32) -> i32 {
    |x| x + 1
}

编译器给出的错误是：

error[E0277]: the trait bound `std::ops::Fn(i32) -> i32 + 'static:
std::marker::Sized` is not satisfied
 -->
  |
1 | fn returns_closure() -> Fn(i32) -> i32 {
  |                         ^^^^^^^^^^^^^^ `std::ops::Fn(i32) -> i32 + 'static`
  does not have a constant size known at compile-time
  |
  = help: the trait `std::marker::Sized` is not implemented for
  `std::ops::Fn(i32) -> i32 + 'static`
  = note: the return type of a function must have a statically known size

错误又一次指向了 Sized trait！Rust 并不知道需要多少空间来储存闭包。在上一部分见过这种情况的解决办法，可以使用 trait 对象：

fn returns_closure() -> Box<dyn Fn(i32) -> i32> {
    Box::new(|x| x + 1)
}

fn main() {
    println!("call return closure: {}", returns_closure()(5));
}

从根本上来说，宏是一种为写其他代码而写代码的方式，即所谓的 元编程

     在附录 C 中会探讨 derive 属性，其生成各种 trait 的实现

     在本书中使用过 println! 宏和 vec! 宏

     所有的这些宏以 “展开” 的方式来生成比所手写出的更多的代码

元编程对于 减少 大量编写和维护的 代码 是非常有用的，它也扮演了函数的角色。但宏有一些函数所没有的附加能力

• 一个 函数 标签必须 声明 函数 参数个数 和 类型 ，宏只接受一个 可变参数

   用一个参数调用 println!("hello") 或用两个参数调用 println!("hello {}", name)

• 宏可以在 编译器翻译代码前 展开

     例如，宏可以在一个给定类型上实现 trait

     而函数则不行，因为函数是在运行时被调用，同时 trait 需要在编译时实现

实现一个宏而不是函数的消极面是 宏定义要比函数定义更复杂

     因为正在编写生成 Rust 代码的 Rust 代码

     由于这样的间接性，宏定义通常要比函数定义更难阅读、理解以及维护

宏和函数的最后一个重要的区别是：在 调用宏之前 必须 定义 并将其 引入作用域 ，而函数则可以在任何地方定义和调用

Rust 最常用的宏形式是 声明宏 。它们有时也被称为 macro_rules! 宏 或者就是 macros 。其核心概念是，声明宏允许编写一些类似 Rust match 表达式 的代码

match 表达式是控制结构，其接收一个表达式，与表达式的结果进行模式匹配，然后根据模式匹配执行相关代码

宏也将一个 值 和 包含相关代码的模式 进行比较：

• 值：传递给宏的 Rust 源代码字面值
• 模式：用于和传递给宏的源代码进行比较，同时 每个模式的相关代码 则用于 替换 传递给宏的代码
• 所有这一切都发生于 编译 时

Rust 使用 macro_rules! 来定义宏。先通过 vec! 宏来探索如何使用 macro_rules! 结构。例如可以用三个整数创建一个 vector：

let v: Vec<u32> = vec![1, 2, 3];

     也可以使用 vec! 宏来构造两个整数的 vector 或五个字符串 slice 的 vector

     但却无法使用函数做相同的事情，因为无法预先知道参数值的数量和类型

下面展示了一个 vec! 稍微简化的定义：

#[macro_export]
macro_rules! vec {
    ( $( $x:expr ),* ) => {
        {
            let mut temp_vec = Vec::new();
            $(
                temp_vec.push($x);
            )*
            temp_vec
        }
    };
}

     注意：标准库中实际定义的 vec! 包括预分配适当量的内存的代码。这部分为代码优化，为了让示例简化，此处并没有包含在内

• 无论何时导入定义了宏的包， #[macro_export] 注解 说明宏应该是 可用 的。 如果没有该注解，这个宏不能被引入作用域
• 接着使用 macro_rules! 和 宏名称 开始宏 定义 ，且所定义的宏并 不带 感叹号。名字后跟 大括号 表示宏 定义体 ，在该例中宏名称是 vec
• vec! 宏的结构和 match 表达式的结构类似。此处有一个单边模式 ( $( $x:expr ),* ) ，后跟 => 以及和 模式相关的代码块 。如果模式匹配，该相关代码块将被执行。假设这是这个宏中唯一的模式，则只有这一种有效匹配，其他任何匹配都是错误的。更复杂的宏会有多个单边模式。
  • 一对 () 包含了 全部模式 。接下来是后跟一对括号的美元符号 $() ，其通过 替代代码 捕获 了 符合括号内模式的值 。$() 内则是 $x:expr ，其匹配 Rust 的 任意表达式 或 给定 $x 名字的表达式
  • $() 之后的 逗号 说明一个 逗号分隔符 可以有选择的 出现 代码之后，这段代码与在 $() 中所捕获的代码相匹配
  • 紧随逗号之后的 * 说明该模式 匹配 零个 或 多个 * 之前的任何模式

     宏定义中有效模式语法和在上一章提及的模式语法是不同的，因为宏模式所匹配的是 Rust 代码结构而不是值

     当以 vec![1, 2, 3]; 调用宏时，$x 模式与三个表达式 1、2 和 3 进行了三次匹配

现在来看看这个出现在与此单边模式相关的代码块中的模式：

• 在 $()* 部分中所生成的 temp_vec.push() 为在匹配到模式中的 $() 每一部分而生成
• $x 由每个与之相匹配的表达式所替换

所以当 vec![1, 2, 3]; 调用该宏时，替换该宏调用所生成的代码会是下面这样：

let mut temp_vec = Vec::new();
// 下面三行就是$x被实际调用中的替换的代码
temp_vec.push(1);
temp_vec.push(2);
temp_vec.push(3);
temp_vec

这样就已经定义了一个宏，其可以接收任意数量和类型的参数，同时可以生成能够创建包含指定元素的 vector 的代码

macro_rules! 中有一些奇怪的地方。会有第二种采用 macro 关键字的声明宏，其工作方式类似但修复了这些极端情况。在此之后，macro_rules! 实际上就过时了

同时鉴于大多数 Rust 程序员“使用”宏而非“编写”宏的事实，此处不再深入探讨 macro_rules!

第二种形式的宏被称为 过程宏 ，因为它们更像函数（一种过程类型）

     过程宏接收 Rust 代码作为输入，在这些代码上进行操作，然后产生另一些代码作为输出

     不是像声明式宏那样匹配对应模式然后以另一部分代码替换当前代码

有三种类型的过程宏，它们的工作方式都类似:

1. 自定义 derive
2. 类属性
3. 类函数

当创建过程宏时，其定义必须位于一种特殊类型的属于它们自己的 crate 中

   这么做出于复杂的技术原因，将来希望能够消除这些限制

使用这些宏需采用类似下面所示的代码形式，其中 some_attribute 是一个使用特定宏的 占位符

use proc_macro;

#[some_attribute]
pub fn some_name(input: TokenStream) -> TokenStream {
}

上面的过程宏包含一个函数，这个函数接受一个 TokenStream 作为输入并产生一个 TokenStream 作为输出。这也就是宏的核心：宏所处理的源代码组成了输入 TokenStream，同时宏生成的代码是输出 TokenStream：

• 函数上有一个属性；这个属性表明过程宏的类型
• 在同一 crate 中可以有多种的过程宏

     这也是其得名的原因：“过程” 是 “函数” 的同义词

     那么为何不叫 “函数宏” 呢？因为有一个过程宏是 “类函数” 的，叫成函数会产生混乱