diff --git a/README.md b/README.md index 768668e..b006a05 100644 --- a/README.md +++ b/README.md @@ -4,13 +4,12 @@ ## 状态 -- ch17 async & await 施工完毕。 -- 2024 edtion 施工中，若示例代码有误请见谅。 +- 2024 edtion 施工完毕。 PS: * 对照源码位置：[https://github.com/rust-lang/book/tree/main/src][source] -* 每章翻译开头都带有官方链接和 commit hash，若发现与官方不一致，欢迎 Issue 或 PR :) +* 每章翻译开头都带有官方链接和 commit hash 的注释，若发现与官方不一致，欢迎 Issue 或 PR [source]: https://github.com/rust-lang/book/tree/main/src diff --git a/src/appendix-04-useful-development-tools.md b/src/appendix-04-useful-development-tools.md index 66a0c32..d325498 100644 --- a/src/appendix-04-useful-development-tools.md +++ b/src/appendix-04-useful-development-tools.md @@ -1,64 +1,66 @@ ## 附录 D：实用开发工具 -> [appendix-04-useful-development-tools.md](https://github.com/rust-lang/book/blob/main/src/appendix-04-useful-development-tools.md) ->
-> commit 5057f157cd0b35bc7d0dc0af6ef622fa4c480996 + + -本附录，我们将讨论 Rust 项目提供的用于开发 Rust 代码的工具。 +在本附录中，我们将讨论 Rust 项目提供的一些有助于开发 Rust 代码的工具。我们将介绍自动格式化、快速应用警告修复、linter 以及与 IDE 的集成。 ### 通过 `rustfmt` 自动格式化 -`rustfmt` 工具根据社区代码风格格式化代码。很多项目使用 `rustfmt` 来避免编写 Rust 风格的争论：所有人都用这个工具格式化代码！ +`rustfmt` 工具根据社区代码风格格式化代码。很多项目使用 `rustfmt` 来避免编写 Rust 代码风格的争论：所有人都用这个工具格式化代码！ 安装 `rustfmt`： -```console -$ rustup component add rustfmt +Rust 安装默认已包含 rustfmt，因此你的系统上应该已经有 `rustfmt` 和 `cargo-fmt` 程序了。这两个命令类似于 `rustc` 和 `cargo`，其中 `rustfmt` 提供了更细粒度的控制，而 `cargo-fmt` 则理解使用 Cargo 的项目约定。要格式化任何 Cargo 项目，请输入以下命令： + +```sh +$ cargo fmt ``` -这会提供 `rustfmt` 和 `cargo-fmt`，类似于 Rust 同时安装 `rustc` 和 `cargo`。为了格式化整个 Cargo 项目： +运行此命令会格式化当前 crate 中所有的 Rust 代码。这应该只会改变代码风格，而不是代码语义。 + +该命令会为你提供 `rustfmt` 和 `cargo-fmt`，类似于 Rust 同时提供 `rustc` 和 `cargo`。要格式化任何 Cargo 项目，请执行以下命令： ```console $ cargo fmt ``` -运行此命令会格式化当前 crate 中所有的 Rust 代码。这应该只会改变代码风格，而不是代码语义。请查看 [该文档][rustfmt] 了解 `rustfmt` 的更多信息。 +运行此命令会格式化当前 crate 中所有的 Rust 代码。这应该只会改变代码风格，而不是代码语义。有关 `rustfmt` 的更多信息，请参阅 [该文档][rustfmt]。 [rustfmt]: https://github.com/rust-lang/rustfmt ### 通过 `rustfix` 修复代码 -如果你编写过 Rust 代码，那么你可能见过那些有很明显修复方式的编译器警告。例如，考虑如下代码： +`rustfix` 工具已随 Rust 安装一并提供，可以自动修复那些具有明确修复方式的编译器警告，这通常正是你所需要的。你可能已经见过类似的编译器警告。例如，考虑如下代码： 文件名：src/main.rs ```rust -fn do_something() {} - fn main() { - for i in 0..100 { - do_something(); - } + let mut x = 42; + println!("{x}"); } ``` +这里定义变量 `x` 为可变，但是我们从未修改它。Rust 会警告说： + 这里调用了 `do_something` 函数 100 次，不过从未在 `for` 循环体中使用变量 `i`。Rust 会警告说： ```console $ cargo build Compiling myprogram v0.1.0 (file:///projects/myprogram) -warning: unused variable: `i` - --> src/main.rs:4:9 +warning: variable does not need to be mutable + --> src/main.rs:2:9 | -4 | for i in 0..100 { - | ^ help: consider using `_i` instead +2 | let mut x = 0; + | ----^ + | | + | help: remove this `mut` | - = note: #[warn(unused_variables)] on by default - - Finished dev [unoptimized + debuginfo] target(s) in 0.50s + = note: `#[warn(unused_mut)]` on by default ``` -警告中建议使用 `_i` 名称：下划线表明该变量有意不使用。我们可以通过 `cargo fix` 命令使用 `rustfix` 工具来自动采用该建议： +警告中建议移除 `mut` 关键字。我们可以通过运行 `cargo fix` 命令使用 `rustfix` 工具来自动采用该建议： ```console $ cargo fix @@ -72,36 +74,27 @@ $ cargo fix 文件名：src/main.rs ```rust -fn do_something() {} - fn main() { - for _i in 0..100 { - do_something(); - } + let x = 42; + println!("{x}"); } ``` -现在 `for` 循环变量变为 `_i`，警告也不再出现。 - -`cargo fix` 命令可以用于在不同 Rust 版本间迁移代码。版本在附录 E 中介绍。 +变量 `x` 现在是不可变的了，警告也不再出现。 -### 通过 `clippy` 提供更多 lint 功能 +`cargo fix` 命令可以用于在不同 Rust 版本间迁移代码。版本在[附录 E][editions]中介绍。 -`clippy` 工具是一系列 lint 的集合，用于捕捉常见错误和改进 Rust 代码。 +### 使用 Clippy 获取更多 lint -安装 `clippy`： - -```console -$ rustup component add clippy -``` +Clippy 工具是一组 lints 的集合，用于分析你的代码，帮助你捕捉常见错误并改进 Rust 代码。Clippy 已包含在 Rust 的标准安装中。 -对任何 Cargo 项目运行 clippy 的 lint： +要对任何 Cargo 项目运行 Clippy 的 lint，请输入以下命令： ```console $ cargo clippy ``` -例如，如果程序使用了如 pi 这样数学常数的近似值，如下： +例如，你编写了一个程序使用了数学常数，例如 pi，的一个近似值，如下所示，： 文件名：src/main.rs @@ -127,7 +120,7 @@ error: approximate value of `f{32, 64}::consts::PI` found = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#approx_constant ``` -这告诉我们 Rust 定义了更为精确的常量，而如果使用了这些常量程序将更加准确。如下代码就不会导致 `clippy` 产生任何错误或警告： +该错误提示你 Rust 已经定义了一个更精确的 `PI` 常量，如果使用该常量，你的程序会更为正确。你可以将代码改为使用 `PI` 常量。如下代码就不会引发 Clippy 的任何错误或警告： 文件名：src/main.rs @@ -139,17 +132,18 @@ fn main() { } ``` -请查看 [其文档][clippy] 来了解 `clippy` 的更多信息。 +有关 Clippy 的更多信息，请参阅 [其文档][clippy]。 [clippy]: https://github.com/rust-lang/rust-clippy ### 使用 `rust-analyzer` 的 IDE 集成 -为了帮助 IDE 集成，Rust 社区建议使用 [`rust-analyzer`][rust-analyzer]。这个工具是一组以编译器为中心的实用程序，它实现了 [Language Server Protocol][lsp]（一个 IDE 与编程语言之间的通信规范）。`rust-analyzer` 可以用于不同的客户端，比如 [Visual Studio Code 的 Rust analyzer 插件][vscode]。 +为了帮助 IDE 集成，Rust 社区建议使用 [`rust-analyzer`][rust-analyzer]。这个工具是一组以编译器为中心的实用程序，它实现了 [Language Server Protocol][lsp]，一个 IDE 与编程语言之间的通信规范。`rust-analyzer` 可以用于不同的客户端，比如 [Visual Studio Code 的 Rust analyzer 插件][vscode]。 [lsp]: http://langserver.org/ [vscode]: https://marketplace.visualstudio.com/items?itemName=rust-lang.rust-analyzer -访问 `rust-analyzer` 项目的 [主页][rust-analyzer] 来了解如何安装它，然后为你的 IDE 安装 language server 支持。如此你的 IDE 便会获得如自动补全、跳转到定义和 inline error 之类的功能。 +访问 `rust-analyzer` 项目的[主页][rust-analyzer]来了解如何安装它，然后为你的 IDE 安装 language server 支持。如此你的 IDE 便会获得如自动补全、跳转到定义和 inline error 之类的功能。 [rust-analyzer]: https://rust-analyzer.github.io +[editions]: appendix-05-editions.html diff --git a/src/appendix-05-editions.md b/src/appendix-05-editions.md index 7bd55b7..b5327b3 100644 --- a/src/appendix-05-editions.md +++ b/src/appendix-05-editions.md @@ -1,22 +1,21 @@ ## 附录 E：版本 -> [appendix-05-editions.md](https://github.com/rust-lang/book/blob/main/src/appendix-05-editions.md) ->
-> commit 8cf0496bb8e56b683ea3f015871c8631684decf4 + + 早在第一章，我们见过 `cargo new` 在 *Cargo.toml* 中增加了一些有关 `edition` 的元数据。本附录将解释其意义！ -Rust 语言和编译器有一个为期 6 周的发布循环。这意味着用户会稳定得到新功能的更新。其他编程语言发布大更新但不甚频繁；Rust 选择更为频繁的发布小更新。一段时间之后，所有这些小更新会日积月累。不过随着小更新逐次的发布，或许很难回过头来感叹：“哇，从 Rust 1.10 到 Rust 1.31，Rust 的变化真大！” +Rust 语言和编译器有一个为期六周的发布循环，这意味着用户会稳定得到新功能的更新。其他编程语言发布大更新但不甚频繁；Rust 选择更为频繁的发布小更新。一段时间之后，所有这些小更新会日积月累。不过随着小更新逐次的发布，或许很难回过头来感叹：“哇，从 Rust 1.10 到 Rust 1.31，Rust 的变化真大！” -每两到三年，Rust 团队会生成一个新的 Rust **版本**（*edition*）。每一个版本会结合已经落地的功能，并提供一个清晰的带有完整更新文档和工具的功能包。新版本会作为常规的 6 周发布过程的一部分发布。 +大约每两到三年，Rust 团队会生成一个新的 Rust **版本**（*edition*）。每一个版本会结合已经落地的功能，并提供一个清晰的带有完整更新文档和工具的功能包。新版本会作为常规的六周发布过程的一部分发布。 -这为不同的人群提供了不同的功能： +新的版本对不同人群具有不同意义： -- 对于活跃的 Rust 用户，其将增量的修改与易于理解的功能包相结合。 -- 对于非用户，它表明发布了一些重大进展，这意味着 Rust 可能变得值得一试。 -- 对于 Rust 自身开发者，其提供了项目整体的集合点。 +- 对于活跃的 Rust 用户，新版本将这些增量改进整合成一个易于理解的包。 +- 对于非 Rust 用户，它表明发布了一些重大进展，这意味着 Rust 可能变得值得一试。 +- 对于 Rust 自身开发者，它提供了项目整体的集合点。 -在本文档编写时，Rust 有三个可用版本：Rust 2015、Rust 2018 和 Rust 2021。本书基于 Rust 2021 edition 风格编写。 +在本文档编写时，Rust 有四个可用版本：Rust 2015、Rust 2018、Rust 2021 和 Rust 2024。本书基于 Rust 2021 edition 惯用法编写。 *Cargo.toml* 中的 `edition` 字段表明代码应该使用哪个版本编译。如果该字段不存在，其默认为 `2015` 以提供后向兼容性。 @@ -26,4 +25,4 @@ Rust 语言和编译器有一个为期 6 周的发布循环。这意味着用户 有一点需要明确：大部分功能在所有版本中都能使用。开发者使用任何 Rust 版本将能继续接收最新稳定版的改进。然而在一些情况，主要是增加了新关键字的时候，则可能出现了只能用于新版本的功能。只需切换版本即可利用新版本的功能。 -请查看 [Edition Guide](https://rust-lang-nursery.github.io/edition-guide/) 了解更多细节，这是一个完全介绍版本的书籍，包括如何通过 `cargo fix` 自动将代码迁移到新版本。 +请查看 [_Edition Guide_](https://rust-lang-nursery.github.io/edition-guide/) 了解更多细节，这是一个全面介绍不同版本之间差异的书籍，包括如何通过 `cargo fix` 自动将代码迁移到新版本。 diff --git a/src/appendix-06-translation.md b/src/appendix-06-translation.md index 0c58a15..b35ee70 100644 --- a/src/appendix-06-translation.md +++ b/src/appendix-06-translation.md @@ -1,22 +1,20 @@ ## 附录 F：本书译本 -> [appendix-06-translation.md](https://github.com/rust-lang/book/blob/main/src/appendix-06-translation.md) ->
-> commit 4c8d13c52c51f1c62a80b52d7fbd7cc0b63ada43 + + -一些非英语语言的资源。多数仍在翻译中；查阅 [翻译标签][label] 来帮助翻译，或者添加译本链接！ +一些非英语语言的资源。多数仍在翻译中；请查阅[翻译标签][label]来帮助翻译，或者添加译本链接！ [label]: https://github.com/rust-lang/book/issues?q=is%3Aopen+is%3Aissue+label%3ATranslations - [Português](https://github.com/rust-br/rust-book-pt-br) (BR) - [Português](https://github.com/nunojesus/rust-book-pt-pt) (PT) -- [简体中文](https://github.com/KaiserY/trpl-zh-cn) +- 简体中文: [KaiserY/trpl-zh-cn](https://github.com/KaiserY/trpl-zh-cn), [gnu4cn/rust-lang-Zh_CN](https://github.com/gnu4cn/rust-lang-Zh_CN) - [正體中文](https://github.com/rust-tw/book-tw) -- [Українська](https://github.com/pavloslav/rust-book-uk-ua) -- [Español](https://github.com/thecodix/book), [alternate](https://github.com/ManRR/rust-book-es) -- [Italiano](https://github.com/EmanueleGurini/book_it) +- [Українська](https://rust-lang-ua.github.io/rustbook_ukrainian) +- [Español](https://github.com/thecodix/book), [alternate](https://github.com/ManRR/rust-book-es), [Español por RustLangES](https://github.com/RustLangES/rust-book-es) - [Русский](https://github.com/rust-lang-ru/book) -- [한국어](https://github.com/rinthel/rust-lang-book-ko) +- [한국어](https://github.com/rust-kr/doc.rust-kr.org) - [日本語](https://github.com/rust-lang-ja/book-ja) - [Français](https://github.com/Jimskapt/rust-book-fr) - [Polski](https://github.com/paytchoo/book-pl) @@ -25,7 +23,7 @@ - [Esperanto](https://github.com/psychoslave/Rust-libro) - [ελληνική](https://github.com/TChatzigiannakis/rust-book-greek) - [Svenska](https://github.com/sebras/book) -- [Farsi](https://github.com/pomokhtari/rust-book-fa) +- [Farsi](https://github.com/RustFarsi/book), [Persian (FA)](https://github.com/persian-rust/book) - [Deutsch](https://github.com/rust-lang-de/rustbook-de) - [हिंदी](https://github.com/venkatarun95/rust-book-hindi) - [ไทย](https://github.com/rust-lang-th/book-th) diff --git a/src/appendix-07-nightly-rust.md b/src/appendix-07-nightly-rust.md index a787158..4ec5cb3 100644 --- a/src/appendix-07-nightly-rust.md +++ b/src/appendix-07-nightly-rust.md @@ -1,20 +1,19 @@ ## 附录 G：Rust 是如何开发的与 “Nightly Rust” -> [appendix-07-nightly-rust.md](https://github.com/rust-lang/book/blob/main/src/appendix-07-nightly-rust.md) ->
-> commit d44317c3122b44fb713aba66cc295dee3453b24b + + -本附录介绍 Rust 是如何开发的以及这如何影响作为 Rust 开发者的你。 +本附录介绍 Rust 是如何开发的以及这对你作为 Rust 开发者的影响。 ### 无停滞稳定 -作为一个语言，Rust **十分** 注重代码的稳定性。我们希望 Rust 成为你代码坚实的基础，假如持续地有东西在变，这个希望就实现不了。但与此同时，如果不能实验新功能的话，在发布之前我们又无法发现其中重大的缺陷，而一旦发布便再也没有修改的机会了。 +作为一门语言，Rust **十分**注重代码的稳定性。我们希望 Rust 成为你可依赖的坚实基础，假如事务持续地在变化，这个希望就实现不了。但与此同时，如果不能实验新功能的话，在发布之前我们又无法发现其中重大的缺陷，而一旦发布便再也没有修改的机会了。 对于这个问题我们的解决方案被称为 “无停滞稳定”（“stability without stagnation”），其指导性原则是：无需担心升级到最新的稳定版 Rust。每次升级应该是无痛的，并应带来新功能，更少的 bug 和更快的编译速度。 ### Choo, Choo! 发布通道和发布时刻表（Riding the Trains） -Rust 开发运行于一个 **发布时刻表**（_train schedule_）之上。也就是说，所有的开发工作都位于 Rust 仓库的 `master` 分支。发布采用 software release train 模型，其被用于思科 IOS 等其它软件项目。Rust 有三个 **发布通道**（_release channel_）： +Rust 开发运行于一个**发布时刻表**（_train schedule_）之上。也就是说，所有的开发工作都位于 Rust 仓库的 `master` 分支。发布采用 software release train 模型，其被用于思科 IOS 等其它软件项目。Rust 有三个**发布通道**（_release channel_）： - Nightly - Beta @@ -22,13 +21,13 @@ Rust 开发运行于一个 **发布时刻表**（_train schedule_）之上。也 大部分 Rust 开发者主要采用稳定版通道，不过希望实验新功能的开发者可能会使用 nightly 或 beta 版。 -如下是一个开发和发布过程如何运转的例子：假设 Rust 团队正在进行 Rust 1.5 的发布工作。该版本发布于 2015 年 12 月，不过这里只是为了提供一个真实的版本。Rust 新增了一项功能：一个 `master` 分支的新提交。每天晚上，会产生一个新的 nightly 版本。每天都是发布版本的日子，而这些发布由发布基础设施自动完成。所以随着时间推移，发布轨迹看起来像这样，版本一天一发： +如下是一个开发和发布过程如何运转的例子：假设 Rust 团队正在进行 Rust 1.5 的发布工作。该版本发布于 2015 年 12 月，不过这里只是为了提供一个真实的版本。Rust 新增了一项功能：一个 `master` 分支的新提交。每天晚上，会产生一个新的 nightly 版本。每天都是发布版本的日子，而这些发布由发布基础设施自动完成。所以随着时间推移，发布轨迹看起来像这样，版本每晚一发： ```text nightly: * - - * - - * ``` -每 6 周时间，是准备发布新版本的时候了！Rust 仓库的 `beta` 分支会从用于 nightly 的 `master` 分支产生。现在，有了两个发布版本： +每六周时间，是准备发布新版本的时候了！Rust 仓库的 `beta` 分支会从用于 nightly 的 `master` 分支产生。现在，有了两个发布渠道： ```text nightly: * - - * - - * @@ -36,7 +35,7 @@ nightly: * - - * - - * beta: * ``` -大部分 Rust 用户不会主要使用 beta 版本，不过在 CI 系统中对 beta 版本进行测试能够帮助 Rust 发现可能的回归缺陷（regression）。同时，每天仍产生 nightly 发布： +大部分 Rust 用户不会主要使用 beta 版本，不过在 CI 系统中对 beta 版本进行测试能够帮助 Rust 发现可能的回归缺陷（regression）。同时，每晚仍产生 nightly 发布： ```text nightly: * - - * - - * - - * - - * @@ -44,7 +43,7 @@ nightly: * - - * - - * - - * - - * beta: * ``` -比如我们发现了一个回归缺陷。好消息是在这些缺陷流入稳定发布之前还有一些时间来测试 beta 版本！fix 被合并到 `master`，为此 nightly 版本得到了修复，接着这些 fix 将 backport 到 `beta` 分支，一个新的 beta 发布就产生了： +比如我们发现了一个回归缺陷。好消息是在这些回归缺陷流入稳定发布之前还有一些时间来测试 beta 版本！fix 被合并到 `master`，为此 nightly 版本得到了修复，接着这些 fix 将 backport 到 `beta` 分支，一个新的 beta 发布就产生了： ```text nightly: * - - * - - * - - * - - * - - * @@ -52,7 +51,7 @@ nightly: * - - * - - * - - * - - * - - * beta: * - - - - - - - - * ``` -第一个 beta 版的 6 周后，是发布稳定版的时候了！`stable` 分支从 `beta` 分支生成： +第一个 beta 版的六周后，是发布稳定版的时候了！`stable` 分支从 `beta` 分支生成： ```text nightly: * - - * - - * - - * - - * - - * - * - * @@ -62,7 +61,7 @@ beta: * - - - - - - - - * stable: * ``` -好的！Rust 1.5 发布了！然而，我们忘了些东西：因为又过了 6 周，我们还需发布 **新版** Rust 的 beta 版，Rust 1.6。所以从 `beta` 生成 `stable` 分支后，新版的 `beta` 分支也再次从 `nightly` 生成： +好的！Rust 1.5 发布了！然而，我们忘了些东西：因为又过了六周，我们还需发布**下一个** Rust 的 beta 版，Rust 1.6。所以从 `beta` 生成 `stable` 分支后，新版的 `beta` 分支也再次从 `nightly` 生成： ```text nightly: * - - * - - * - - * - - * - - * - * - * @@ -72,29 +71,33 @@ beta: * - - - - - - - - * * stable: * ``` -这被称为 “train model”，因为每 6 周，一个版本 “离开车站”（“leaves the station”），不过从 beta 通道到达稳定通道还有一段旅程。 +这被称为 “train model”，因为每六周，一个版本 “离开车站”（“leaves the station”），不过从 beta 通道到达稳定通道还需历经一段旅程。 -Rust 每 6 周发布一个版本，如时钟般准确。如果你知道了某个 Rust 版本的发布时间，就可以知道下个版本的时间：6 周后。每 6 周发布版本的一个好的方面是下一班车会来得更快。如果特定版本碰巧缺失某个功能也无需担心：另一个版本很快就会到来！这有助于减少因临近发版时间而偷偷释出未经完善的功能的压力。 +Rust 每六周发布一个版本，如时钟般准确。如果你知道了某个 Rust 版本的发布时间，就可以知道下个版本的时间：六周后。每六周发布版本的一个好的方面是下一班车会来得更快。如果特定版本碰巧缺失某个功能也无需担心：另一个版本很快就会到来！这有助于减少因临近发版时间而偷偷释出未经完善的功能的压力。 -多亏了这个过程，你总是可以切换到下一版本的 Rust 并验证是否可以轻易的升级：如果 beta 版不能如期工作，你可以向 Rust 团队报告并在发布稳定版之前得到修复！beta 版造成的破坏是非常少见的，不过 `rustc` 也不过是一个软件，可能会存在 bug。 +多亏了这个过程，你总是可以切换到下一版本的 Rust 并验证是否可以轻易的升级：如果 beta 版不能如期工作，你可以向 Rust 团队报告并在发布稳定版之前得到修复！beta 版造成的破坏是非常少见的，不过 `rustc` 也不过是一个软件，难免会有 bug。 + +### 维护时间 + +Rust 项目仅对最近的稳定版本提供支持。当发布新稳定版本时，旧版本即达到生命周期终止（EOL, end of life），这意味着每个版本的支持期为六周。 ### 不稳定功能 -这个发布模型中另一个值得注意的地方：不稳定功能（unstable features）。Rust 使用一个被称为 “功能标记”（“feature flags”）的技术来确定给定版本的某个功能是否启用。如果新功能正在积极地开发中，其提交到了 `master`，因此会出现在 nightly 版中，不过会位于一个 **功能标记** 之后。作为用户，如果你希望尝试这个正在开发的功能，则可以在源码中使用合适的标记来开启，不过必须使用 nightly 版。 +这个发布模型中另一个值得注意的地方：不稳定功能（unstable features）。Rust 使用一个被称为 “功能标记”（“feature flags”）的技术来确定给定版本的某个功能是否启用。如果新功能正在积极地开发中，其提交到了 `master`，因此会出现在 nightly 版中，不过会位于一个 **功能标记** 之后。作为用户，如果你希望尝试这个正在开发的功能，必须使用 nightly 版并在源码中使用合适的标记来开启。 -如果使用的是 beta 或稳定版 Rust，则不能使用任何功能标记。这是在新功能被宣布为永久稳定之前获得实用价值的关键。这既满足了希望使用最尖端技术的同学，那些坚持稳定版的同学也知道其代码不会被破坏。这就是无停滞稳定。 +如果使用的是 beta 或稳定版 Rust，则不能使用任何功能标记。这是在新功能被宣布为永久稳定之前让大家提前实际使用它们的关键。这既满足了希望使用最尖端技术的同学，那些坚持稳定版的同学也知道其代码不会被破坏。这就是无停滞稳定。 -本书只包含稳定的功能，因为还在开发中的功能仍可能改变，当其进入稳定版时肯定会与编写本书的时候有所不同。你可以在网上获取 nightly 版的文档。 +本书只包含稳定的功能，因为还在开发中的功能仍可能改变，当其进入稳定版时肯定会与编写本书的时候有所不同。你可以在网上获取只存在 nightly 版中功能的文档。 ### Rustup 和 Rust Nightly 的职责 -Rustup 使得改变不同发布通道的 Rust 更为简单，其在全局或分项目的层次工作。其默认会安装稳定版 Rust。例如为了安装 nightly： +Rustup 使得改变不同发布通道的 Rust 更为简单，其在全局或分项目的层次工作。其默认会安装稳定版 Rust。例如，为了安装 nightly： ```console $ rustup toolchain install nightly ``` -你会发现 `rustup` 也安装了所有的 **工具链**（_toolchains_，Rust 和其相关组件）。如下是一位作者的 Windows 计算机上的例子： +你会发现 `rustup` 也安装了所有的**工具链**（_toolchains_，Rust 和其相关组件）。如下是一位作者的 Windows 计算机上的例子： ```powershell > rustup toolchain list @@ -110,14 +113,14 @@ $ cd ~/projects/needs-nightly $ rustup override set nightly ``` -现在，每次在 _~/projects/needs-nightly_ 调用 `rustc` 或 `cargo`，`rustup` 会确保使用 nightly 版 Rust。在你有很多 Rust 项目时大有裨益！ +现在，每次在 _~/projects/needs-nightly_ 中调用 `rustc` 或 `cargo`，`rustup` 会确保使用 nightly 版 Rust 而非默认的稳定版。在你有很多 Rust 项目时大有裨益！ -### RFC 过程和团队 +### RFC 流程和团队 -那么你如何了解这些新功能呢？Rust 开发模式遵循一个 **Request For Comments (RFC) 过程**。如果你希望改进 Rust，可以编写一个提议，也就是 RFC。 +那么你如何了解这些新功能呢？Rust 开发模式遵循一个 **Request For Comments (RFC) 流程**。如果你希望改进 Rust，可以编写一个提案，也就是 RFC。 -任何人都可以编写 RFC 来改进 Rust，同时这些 RFC 会被 Rust 团队评审和讨论，他们由很多不同分工的子团队组成。这里是 [Rust 官网上](https://www.rust-lang.org/governance) 所有团队的总列表，其包含了项目中每个领域的团队：语言设计、编译器实现、基础设施、文档等。各个团队会阅读相应的提议和评论，编写回复，并最终达成接受或回绝功能的一致。 +任何人都可以编写 RFC 来改进 Rust，同时这些 RFC 会被 Rust 团队评审和讨论，他们由很多不同分工的子团队组成。这里是 [Rust 官网上](https://www.rust-lang.org/governance) 所有团队的总列表，其包含了项目中每个领域的团队：语言设计、编译器实现、基础设施、文档等。各个团队会阅读相应的提议和评论，发表自己的意见，并最终达成接受或回绝功能的一致。 如果功能被接受了，在 Rust 仓库会打开一个 issue，人们就可以实现它。实现功能的人当然可能不是最初提议功能的人！当实现完成后，其会合并到 `master` 分支并位于一个功能开关（feature gate）之后，正如 [“不稳定功能”](#不稳定功能) 部分所讨论的。 -在稍后的某个时间，一旦使用 nightly 版的 Rust 团队能够尝试这个功能了，团队成员会讨论这个功能，它如何在 nightly 中工作，并决定是否应该进入稳定版。如果决定继续推进，功能开关会移除，然后这个功能就被认为是稳定的了！乘着“发布的列车”，最终在新的稳定版 Rust 中出现。 +在稍后的某个时间，一旦使用 nightly 版的 Rust 团队能够尝试这个功能了，团队成员会讨论这个功能，它如何在 nightly 中工作，并决定是否应该进入稳定版。如果决定继续推进，功能开关会移除，然后这个功能就被认为是稳定的了！乘着“发布列车”，最终在新的稳定版 Rust 中出现。