统一“three-way”的翻译

02.md

@@ -276,7 +276,7 @@ Boost 库和 Boost 组织非常重要 [Boost 1998–2020]。1998 年，经验丰
 - `variant`、`any` 和 `optional`——显然受到多种语言的启发（[§8.3](08.md#83-variantoptional-和-any)）。
 -  lambda 表达式——显然，部分灵感来自于函数式语言中 lambda 表达式的应用。但是，在 C++ 中，lambda 表达式的根源还可以上溯到 BCPL 语言中用作表达式的代码块、局部函数（多次被 C 和 C++ 拒绝，因其容易出错且增加了复杂性）和（最重要的）函数对象（[§4.3.1](04.md#431-lambda-表达式)）。
 - `final` 和 `override`——用于更明确地管理类层次结构，并且在许多面向对象的语言中都可以使用。在早期的 C++ 中已经考虑过它们了，但当时被认为是不必要的。
-- 三向比较运算符 `<=>`，受 C 的 `strcmp` 及 PERL、PHP、Python 和 Ruby 语言的运算符的启发（[§9.3.4](09.md#934-)）。
+- 三路比较运算符 `<=>`，受 C 的 `strcmp` 及 PERL、PHP、Python 和 Ruby 语言的运算符的启发（[§9.3.4](09.md#934-)）。
 - `await`——C++ 里最早的协程（[§1.1](01.md#11-年表)）受 Simula 启发，但是作为库提供，而不是作为语言特性，这是为了给其他替代的并发技术留出空间。C++20 中的无栈协程的思想主要来自 F#（[§9.3.2](09.md#932-协程)）。
 
 即使以非常直接的方式从另一种语言借用了某个特性，该特性也会发生变化。通常，为了适合 C++ 语法会发生很大变化。当从支持垃圾收集的语言借鉴时，生命周期问题必须得到解决。而 C++ 区分对象和对象的引用，这通常使得 C++ 需要以和原语言不同的方式来解决。在“翻译”成 C++ 的过程中，经常会发现全新的用法。在把 lambda 引入 C++ 的过程中，出现了大量此类现象的例子（[§4.3.1](04.md#431-lambda-表达式)）。

09.md

@@ -85,7 +85,7 @@ WG21 将针对 C++20 的新提案的截止日期定为 2018 年 11 月，并在
 - [§9.3.1](#931-模块)：**模块**——支持代码的模块化，使代码更卫生并改善编译时间
 - [§9.3.2](#932-协程)：**协程**——无栈协程
 - [§9.3.3](#933-编译期计算支持)：**编译期**计算支持
-- [§9.3.4](#934-)：**<=>**——三向比较运算符
+- [§9.3.4](#934-)：**<=>**——三路比较运算符
 - [§9.3.5](#935-范围)：**范围**——提供灵活的范围抽象的库
 - [§9.3.6](#936-日期和时区)：**日期**——提供日期类型、日历和时区的库
 - [§9.3.8](#938-跨度)：**跨度**——提供对数组进行高效和安全访问的库
@@ -290,7 +290,7 @@ C++ 从 C 继承了只限于整型且不能调用函数的常量表达式。曾
 
 ### 9.3.4 <=>
 
-参见（[§8.8.4](08.md#884-缺省比较)）。紧接在“飞船运算符”（`<=>`）投票进入 C++20 之后，很明显，在语言规则及其与标准库的集成方面都需要进一步的认真工作。出于对解决跟比较有关的棘手问题的过度热情和渴望，委员会成了意外后果定律的受害者。一些委员（包括我在内）担心引入 `<=>` 过于仓促。然而，在我们的担忧坐实的时候，早已经有很多工作在假设 `<=>` 可用的前提下完成了。此外，三向比较可能带来的性能优势让许多委员会成员和其他更广泛的 C++ 社区成员感到兴奋。因此，当发现 `<=>` 在重要用例中导致了显著的低效时，那就是一个相当令人不快的意外了。类型有了 `<=>` 之后，`==` 是从 `<=>` 生成的。对于字符串，`==` 通常通过首先比较大小来优化：如果字符数不同，则字符串不相等。从 `<=>` 生成的 `==` 则必须读取足够的字符串以确定它们的词典顺序，那开销就会大得多了。经过长时间的讨论，我们决定不从 `<=>` 生成 `==`。这一点和其他一些修正 [Crowl 2018; Revzin 2018, 2019; Smith 2018c] 解决了手头的问题，但损害了 `<=>` 的根本承诺：所有的比较运算符都可以从一行简单的代码中生成。此外，由于 `<=>` 的引入，`==` 和 `<` 现在有了许多不同于其他运算符的规则（例如，`==` 被假定为对称的）。无论好坏，大多数与运算符重载相关的规则都将 `<=>` 作为特例来对待。
+参见（[§8.8.4](08.md#884-缺省比较)）。紧接在“飞船运算符”（`<=>`）投票进入 C++20 之后，很明显，在语言规则及其与标准库的集成方面都需要进一步的认真工作。出于对解决跟比较有关的棘手问题的过度热情和渴望，委员会成了意外后果定律的受害者。一些委员（包括我在内）担心引入 `<=>` 过于仓促。然而，在我们的担忧坐实的时候，早已经有很多工作在假设 `<=>` 可用的前提下完成了。此外，三路比较可能带来的性能优势让许多委员会成员和其他更广泛的 C++ 社区成员感到兴奋。因此，当发现 `<=>` 在重要用例中导致了显著的低效时，那就是一个相当令人不快的意外了。类型有了 `<=>` 之后，`==` 是从 `<=>` 生成的。对于字符串，`==` 通常通过首先比较大小来优化：如果字符数不同，则字符串不相等。从 `<=>` 生成的 `==` 则必须读取足够的字符串以确定它们的词典顺序，那开销就会大得多了。经过长时间的讨论，我们决定不从 `<=>` 生成 `==`。这一点和其他一些修正 [Crowl 2018; Revzin 2018, 2019; Smith 2018c] 解决了手头的问题，但损害了 `<=>` 的根本承诺：所有的比较运算符都可以从一行简单的代码中生成。此外，由于 `<=>` 的引入，`==` 和 `<` 现在有了许多不同于其他运算符的规则（例如，`==` 被假定为对称的）。无论好坏，大多数与运算符重载相关的规则都将 `<=>` 作为特例来对待。
 
 ### 9.3.5 范围