《Rust 程序设计语言》全书摘要与逐章导读

“加密货币、生物信息学、搜索引擎”

“cryptocurrencies, bioinformatics, search engines”

公司采用的清单做着论证的工作：以广度证明成熟。但一份领域的清单不是一份结果的清单——从来没有人列出被放弃的 Rust 重写。

“没有这些检查的语言里那些脆弱的遗留代码，开发者往往不敢去修改”

“the brittle legacy code in languages without these checks, which developers are often afraid to modify”

本章情感上最精确的一句话。Rust 真正的卖点不是速度或安全——而是重新获得碰自己代码的许可。

“如果你完全是编程新手，你最好”

“If you’re entirely new to programming, you would be better served”

诚实，却悄悄地与两页之前的“学生”一节相矛盾，那一节承诺让系统概念“对更多的人变得可及，尤其是编程新手”。欢迎的地垫上有一级台阶。

“我们会提供许多无法编译的例子，连同错误信息”

“we’ll provide many examples that don’t compile along with the error message”

一种真正不寻常的教学承诺：把失败当作主要的文本来教，而不是当作附录。大多数语言书都把它们的坏代码藏起来。

“在大多数情况下，我们会引导你找到任何无法编译的代码的正确版本。”

“In most situations, we’ll lead you to the correct version of any code that doesn’t compile.”

这句话连续出现了两次——第二次孤零零地搁在 Ferris 表格应该在的地方。一条说明，在转换成纯文本时丢了它的图片。

“Finished dev [unoptimized + debuginfo] target(s) in 2.85 secs”

过时的输出：现代的 Cargo 打印的是 dev profile，而 secs 早就变成了 s。承诺向前兼容的这一章，自己却在展示过去。

“语言设计中，一切都是取舍。”

“Everything is a trade-off in language design.”

本章唯一一句里没有命令的话。一句平淡的旁白，悄悄为此后的每一项妥协颁发了许可——预先编译、借用检查器、整本书。

“万物各有其位，万物各在其位。”

“There’s a place for everything, and everything is in its place.”

一种童谣节奏做着意识形态的工作：约定被兜售为舒适，而不是约束。Cargo 的主张是穿着整洁的外衣到来的。

“这使你成为一名 Rust 程序员——欢迎！”

“That makes you a Rust programmer—welcome!”

敲六行字就授予了身份。再加上“Rustacean”，这一章在教你任何一个概念之前，就把你纳入了一个社区——社会性的安装，与软件的安装并行。

“warning: unused `Result` that must be used”

书有意让你看到失败。Rust 真正的老师是编译器，而作者们知道这一点——他们在训练你读诊断，而不是背规则。

“我们只想在出问题时让这个程序崩溃，所以可以使用 expect”

“we just want to crash this program when a problem occurs, so we can use expect”

至少对捷径是诚实的。但 expect 是一千个初学者代码库僵化的地方——教程的脚手架成了某个人的生产习惯。

“请注意，这段代码现在还不能编译，我们会解释的。”

“Note that this code won’t compile just yet, as we will explain.”

他们有意制造一个类型错误。把 String 对整数展示成一次亲身经历的碰撞，比任何一段关于静态类型的文字教得都多。

“Cargo 忽略 0.999.0 这个版本。”

“Cargo ignores the 0.999.0 release.”

一个荒谬的假版本号，让脱字符规则变得可感。0.999.0 无法从 0.10.1 到达——这一点之所以落地，恰恰因为差距是滑稽的。

“幸好，Rust 允许我们用一个新值遮蔽 guess 先前的值”

“helpfully Rust allows us to shadow the previous value of guess with a new one”

“幸好（helpfully）”在做说服的工作。遮蔽也是新手读别人代码时最令人困惑的唯一特性——书在读者能反对之前就把它卖了出去。

“这个示例程序中的 u32 标注，以及与 secret_number 的比较，意味着 Rust 会推断 secret_number 也应当是 u32”

“the u32 annotation in this example program and the comparison with secret_number means Rust will infer that secret_number should be a u32 as well”

这是本章安静的亮点：一个类型决定向后流过整个程序。底部的一个标注，向上够到并确定了一个更早声明的变量。

“比如，如果字符串里含有 A👍%，就没有办法把它转换成数字。”

“If, for example, the string contained A👍%, there would be no way to convert that to a number.”

那个表情符号是个玩笑，却也是个真实的要点——Rust 的字符串默认是 UTF-8，所以这不是个假想的输入。

“但还有另一种办法，可以逃脱这个贪得无厌的怪物”

“But there’s another way to escape this insatiable monster”

把一个 bug 当作出口来教。诚实而好笑，但在收回之前，它悄悄地把“崩溃”当作面向用户的特性，常态化了整整两页。

“退出循环也意味着退出程序，因为循环是 main 的最后一部分。”

“Exiting the loop also means exiting the program, because the loop is the last part of main.”

一行提醒：控制流是有形的——你把花括号放在哪里，决定了 break 的含义。

“Err(_) => continue,”

从 expect 到 match 的整个转变，装进两行，而 continue 作为 match 分支的值才是真正的惊喜：控制流坐在一个本应是表达式的位置上。书滑过了这一点，没有点名。

“所以，实际上，程序忽略了 parse 可能遇到的所有错误！”

“So, effectively, the program ignores all errors that parse might encounter!”

对一件书在别处警告要避免的事，措辞欢快。悄悄吞掉每一个错误，恰恰是第9章将不得不撤销的习惯。

“我们可以对一个值做几次变换，但在这些变换完成之后，变量是不可变的”

“we can perform a few transformations on a value but have the variable be immutable after those transformations have completed”

遮蔽是不让你失去保证的逃生口——构造期间可变，之后不可变。优雅，也是让每个读一串 let x 的新手困惑的东西。

“依赖整数溢出的回绕行为，被视为一个错误。”

“Relying on integer overflow’s wrapping behavior is considered an error.”

调试时 panic，发布时悄悄回绕——所以同样的代码，因标志而有两种语义。书把依赖它称为错误，但它仍是你在生产中可能绊倒、却在测试中永远碰不到的、已交付的行为。

“字符”在 Unicode 里其实不是一个概念，所以你人类直觉里的“字符”，可能与 Rust 里的 char 不吻合”

“a “character” isn’t really a concept in Unicode, so your human intuition for what a “character” is may not match up with what a char is in Rust”

到目前为止最诚实的一句话。Rust 没有糊弄这个泄漏——它把 char 点名为一个方便的谎言，并把清算推迟到第8章。

“如果你不确定该用数组还是向量，那么很可能你应该用向量。”

“If you’re unsure whether to use an array or a vector, chances are you should use a vector.”

直白，值得注意：本章认真地教了数组，然后告诉你大多不要用它们。无论如何教栈分配的情形，是为了建立第4章的直觉，而不是为了实践。

“这个检查必须在运行时发生，尤其是在这种情形下，因为编译器不可能知道用户会输入什么值”

“This check has to happen at runtime, especially in this case, because the compiler can’t possibly know what value a user will enter”

对静态保证的局限的一个安静的让步：这里的安全，是靠运行时代价和一次崩溃买来的，而不是证明。Rust 的承诺是“没有无效的内存访问”，从来不是“没有失败”。

“要求在函数定义里写类型标注，意味着编译器几乎不需要你在别处使用它们”

“Requiring type annotations in function definitions means the compiler almost never needs you to use them elsewhere”

一处不错的设计诚实：摩擦不是税，而是边界契约。标注门口，推断内部。

“let x = (let y = 6);”

本章靠有意弄坏东西来教学。注意错误信息悄悄透露了什么——let 允许出现在 if/while 条件里，这暗示了文字没有深究的 let 链。

“你可以写 x = y = 6，让 x 和 y 都有值 6；在 Rust 里并非如此”

“you can write x = y = 6 and have both x and y have the value 6; that is not the case in Rust”

Rust 放弃了 C 的一个便利，来杀死经典的 if (x = 0) 这一类 bug。这里的每一项限制，都是某个人已经付过款的交易。

“如果你在表达式的末尾加上分号，你就把它变成了语句，它就不会再返回值了。”

“If you add a semicolon to the end of an expression, you turn it into a statement, and it will then not return a value.”

一个字符改变了一个函数的含义。这单一的一句话，解释了大多数初学者的 Rust 错误——而编译器的“请去掉这个分号”的提示就是证明。

“隐式返回 `()`，因为它的函数体没有尾表达式或 `return` 表达式”

“implicitly returns `()` as its body has no tail or `return` expression”

单元类型不请自来，作为无的形状。值得注意，Rust 没有无声的“没有值”——缺失本身是有类型的。

“Rust 不会自动尝试把非布尔类型转换成布尔类型”

“Rust will not automatically try to convert non-Boolean types to a Boolean”

没有真值性。JavaScript 多年来 if (0)/if (“”) 的民间传说消失了——你必须说出你真正的意思。

“编译器会更复杂，对代码做出的保证也更少”

“the compiler would be more complex and would make fewer guarantees about the code”

难得一见的时刻，书从编译器的利益而不是程序员的利益出发来论证。这条规则不是任意的；它是你所购买的保证的价格。

“你可以在 break 表达式之后添加想要返回的值”

“you can add the value you want returned after the break expression”

break 携带一个值，使 loop 也成为表达式——这是语句一节里同样的“一切都求值”的逻辑，现在应用于控制流。这一章比它看上去的要统一。

“它也很慢，因为编译器添加了运行时代码来执行条件检查”

“It’s also slow, because the compiler adds runtime code to perform the conditional check”

我要稍微反驳一下：对固定大小数组的边界检查，常常被优化掉。for 真正的胜利是正确性，而本章自己的第一个论证已经提出了它。

“这段代码好看一点，不是吗？”

“This code is a bit nicer, isn’t it?”

书唯一一次直截了当的哄劝。按谁的标准好看？它从未说——它只是假定你会点头，这就是品味被传递而不是被论证的方式。

“大多数 Rustacean 会用 for 循环”

“most Rustaceans would use a for loop”

诉诸部落习俗，而不是诉诸编译器。注意，安全论证和社区习惯论证被融合进了一句话——方便。

“for number in (1..4).rev”

悄悄地是本章最棘手的一行：1..4 排除 4，然后 rev 把它翻转，所以你必须同时持有两条差一规则，才能得到 3,2,1。却被当作更简单的选项来兜售。

“我们需要让恰好一次分配，与恰好一次释放配对。”

“We need to pair exactly one allocate with exactly one free.”

就在上面列出的四种失败模式，全都出自一条簿记规则。Rust 的回答不是一个更好的程序员——而是把簿记从人的工作中删除。

“但因为 Rust 还使第一个变量失效，它不叫做浅拷贝，而称为移动。”

“But because Rust also invalidates the first variable, instead of being called a shallow copy, it’s known as a move.”

整章的支点，而且纯粹是关于什么被拿走了。移动是浅拷贝加一次删除——删除就是整个发明。

“Rust 永远不会自动创建你数据的“深”拷贝。”

“Rust will never automatically create “deep” copies of your data.”

这是一条成本可见性的原则，而不是内存原则。开销必须被写明——这就是为什么 clone 是个你必须敲出来的词。

“当你看到对 clone 的调用时，你就知道有一些任意的代码正在被执行，而那些代码可能很昂贵。”

“When you see a call to clone, you know that some arbitrary code is being executed and that code may be expensive.”

语法作为性能的异味。别的语言把这藏在一个 = 后面；Rust 让读代码的人，而不只是写代码的人，能够看到账单。

“如果一个类型，或它的任何部分，实现了 Drop trait，Rust 就不会让我们给这个类型标注 Copy。”

“Rust won’t let us annotate a type with Copy if the type, or any of its parts, has implemented the Drop trait.”

Copy 和 Drop 必然是互斥的——如果清理要紧，复制就不可能免费。这条规则不是任意的策略；它从一次分配对一次释放的算术中掉出来。

“但对于一个本应常见的概念来说，这太繁文缛节，也太费事了。”

“But this is too much ceremony and a lot of work for a concept that should be common.”

优雅的教学结构：先让读者感受到纯所有权的摩擦，然后再提供引用作为解脱。那段元组代码的存在，只是为了被怨恨。

“与指针不同，引用保证在该引用的生命周期内，指向某种特定类型的有效值。”

“Unlike a pointer, a reference is guaranteed to point to a valid value of a particular type for the life of that reference.”

把引用与 C 指针区分开来的那一句话，几乎是随口丢出的。本章其余部分一切困难的东西——生命周期、借用规则——都是那个保证的代价。

“我们把创建引用的动作称为借用。就像在现实生活中，如果一个人拥有某样东西，你可以向他们借。”

“We call the action of creating a reference borrowing. As in real life, if a person owns something, you can borrow it from them.”

这个比喻在这里做了很多工作，但注意它在后面悄悄破裂了：在现实生活里，你不能把同一本书借给两个人，却可以让满满一屋子人从你肩膀上看。&/&mut 的划分恰恰就是那种不对称——这个类比之所以能存活，只因为阅读是非破坏性的。

“剧透警告：行不通！”

“Spoiler alert: It doesn’t work!”

书靠有意领你走到墙边来教学。欢快的语气作为麻醉剂——你把 E0596 当作玩笑而不是失败来遇见。

“不可变引用的使用者，不期望值突然在他们底下改变！”

“Users of an immutable reference don’t expect the value to suddenly change out from under them!”

这是使整条规则变得直观的那一句话——限制不是官僚主义，而是兑现类型已经对其读者做出的承诺。

“编译器可以判断，在作用域结束之前的某一点，这个引用不再被使用了。”

“The compiler can tell that the reference is no longer being used at a point before the end of the scope.”

这一节里悄悄地最重要的让步：规则是关于使用的生命周期，而不是词法上的花括号。没有 NLL，这一章读起来会像暴政。

“它只有在 &String 的上下文中才是一个有意义的数字”

“it’s only a meaningful number in the context of the &String”

切片真正的论点，而且根本不是关于字符串的：一个没有与其来源绑定的派生值，是一个等着定日程的 bug。Rust 的回答，是让这条绑定成为类型的一部分。

“这个程序编译没有任何错误”

“This program compiles without any errors”

本章最可怕的一行。基于索引的代码在编译器看来是正确的，在我们看来是错的——这是诚实的承认：安全只覆盖你在类型中编码的东西。

“Rust 不仅让我们的 API 更容易使用，还在编译期消除了整整一类错误！”

“Not only has Rust made our API easier to use, but it has also eliminated an entire class of errors at compile time!”

注意顺序里的障眼法：人体工学在先，安全在后。本章真正的论证是，安全的设计碰巧也是更好的设计——否则就没人会容忍借用检查器。

“这也是字符串字面量不可变的原因；&str 是不可变引用。”

“This is also why string literals are immutable; &str is an immutable reference.”

一个你在第3章背下来的事实，突然成了后果，而不是规则。那种追溯的点击，是本章最好的时刻。

“即使两种类型都由三个 i32 值构成，接受 Color 类型参数的函数也不能接受 Point 作为参数”

“a function that takes a parameter of type Color cannot take a Point as an argument, even though both types are made up of three i32 values”

一行说完元组结构体的全部要点：身份压过形状。类型系统让你做出数据本身无法表达的区分。

“把宽和高搞混，对面积的计算没有影响，但如果我们想把矩形画在屏幕上，就有影响了！”

“Mixing up the width and height wouldn’t matter for the area calculation, but if we want to draw the rectangle on the screen, it would matter!”

论证的诚实版本。元组在这里并没有错——它们在后来错了，当代码增长的时候。未命名数据的代价是被推迟的，这恰恰就是人们对它投入的关注不足的原因。

“由于这种含糊，Rust 不会试图猜测我们想要什么”

“Due to this ambiguity, Rust doesn’t try to guess what we want”

Rust 反复出现的气质：在默认值会是任意的地方，拒绝默认。别的语言欣然打印 <Object at 0x...>；Rust 让你说出输出是给哪个受众的。

“直接面向终端用户消费的输出”

“output intended for direct end user consumption”

Display/Debug 的划分不是技术上的，而是关于谁在读。一个类型可以有两种展示方式，因为它有两种受众——大多数语言从不费心去划出的区分。

“它获取表达式的所有权（不同于 println!，后者获取引用），打印文件和行号”

“which takes ownership of an expression (as opposed to println!, which takes a reference), prints the file and line number”

一个必须把值交回来的调试宏——所有权把就连 printf 式调试，也变成了谁持有什么的问题。优雅的是，dbg! 把它返回，这样你就可以原地包裹任何表达式。

“&self 实际上是 self: &Self 的简写。”

“The &self is actually short for self: &Self.”

脱糖是澄清的动作——self 不是像 this 那样的魔法关键字，而是一个带语法糖的普通第一参数。这也就是它为什么能是 self、&self 或 &mut self 的原因。

“这种技术通常用于方法把 self 转换成别的东西，而你想防止调用者使用原来的实例的时候”

“this technique is usually used when the method transforms self into something else and you want to prevent the caller from using the original instance”

消耗 self 作为一个特性：API 编码了“这个东西现在用完了”。大多数语言里，你根本无法在签名里表达这样的保证。

“我们可以在同名方法中出于任何目的使用同名的字段。”

“We can use a field within a method of the same name for any purpose.”

悄悄承认 Rust 在这里容忍真正的含糊，只是靠括号来解决。对编译器是可读的，对略读的人则令人困惑——书从未这么说。

“Rust 不像某些其他语言那样，为结构体字段自动实现它们”

“Rust does not implement them automatically for struct fields as some other languages do”

陈述得很中性，但这是一种设计立场：没有免费的 getter，就没有“每个字段都想被读取”的错觉。把样板代码作为有意的减速带。

“给定方法的接收者和名字，Rust 可以确凿地判断该方法是在读（&self）、修改（&mut self）还是消耗（self）。”

“Given the receiver and name of a method, Rust can figure out definitively whether the method is reading (&self), mutating (&mut self), or consuming (self).”

真正的论证落在这里：隐式之所以安全，只因为签名已经固定了意图。别处 Rust 之所以拒绝猜测，恰恰因为没有这样的锚点。

“这些通常叫做 new，但 new 不是一个特殊的名字，也不是内置于语言的”

“These are often called new, but new isn’t a special name and isn’t built into the language”

书里最好的句子之一。在别的语言里看起来像关键字的东西，在这里只是一个约定——构造从仪式被降格为一个普通的函数。

“返回类型和函数体中的 Self 关键字，是 impl 关键字后面出现的那个类型的别名”

“The Self keywords in the return type and in the body of the function are aliases for the type that appears after the impl keyword”

现在小，之后承重：Self 让一个 impl 块可以在不知道自己具体名字的情况下被编写——泛型和 trait 的种子。

“这里没有理由把这些方法拆分到多个 impl 块里，但这是有效的语法。”

“There’s no reason to separate these methods into multiple impl blocks here, but this is valid syntax.”

令人钦佩的诚实教学：这里有一项眼下没有用处的能力。在动机之前引入机制是一场赌博，而作者知道这一点，所以有了指向第10章的期票。

“我们定义的每个枚举变体的名字，也成为构造该枚举实例的一个函数。”

“The name of each enum variant that we define also becomes a function that constructs an instance of the enum.”

被当作“另一个细节”溜进来，但这就是 .map(Some) 和 ids.into_iter().map(IpAddr::V6) 之所以能工作的原因。变体是函数，是一个承重的事实，而不是脚注。

“每枚硬币都落进它遇到的、它适合的第一个洞”

“each coin falls through the first hole it encounters that it fits into”

这个比喻做了实事：它编码了对顺序的依赖，这是初学者经常绊倒的地方。后面的分支可能是死代码，而机器的意象，在规则被陈述之前，就让这一点直观了。

“好家伙！”

“Intense!”

难得的时刻，书打破语域，承认它自己那一大堆输出。这种诚实是策略性的——一个盯着十行 trait 说明的初学者，需要许可不去读完所有这些。

“从而使前面讨论的十亿美元的错误成为不可能”

“thus making the billion-dollar mistake discussed earlier impossible”

本章在这里闭合了自己的圈：霍尔的悔恨和穷尽性检查，一直是同一个论证。但“不可能”做了很重的活；unwrap() 仍然只差一次击键。

“所以如果我们在兜底分支之后添加分支，Rust 会警告我们！”

“so Rust will warn us if we add arms after a catch-all!”

漂亮：编译器不仅强制执行穷尽性，还监管死掉的模式。顺序很要紧，但你不会悄无声息地把它弄错。

“这告诉 Rust 我们不打算使用这个值，所以 Rust 不会就未使用的变量警告我们”

“This tells Rust we aren’t going to use the value, so Rust won’t warn us about an unused variable”

_ 与其说是模式，不如说是给编译器的一条消息。Rust 一再把意图变成语法——你声明你本意要忽略什么。

“我们没有忘记任何东西”

“we haven’t forgotten anything”

整章的情感核心，四个字。穷尽性不是关于正确性理论，而是关于忘记一个情形的恐惧。

“这是需要添加的、烦人的样板代码”

“which is annoying boilerplate code to add”

书承认它自己的美德是一种代价。这种诚实就是 if let 一节之所以落地的原因——它是靠读者已经感觉到的一种恼怒挣得的。

“获得简洁是否是对失去穷尽检查的适当取舍”

“whether gaining conciseness is an appropriate trade-off for losing exhaustive checking”

没有提供建议。Rust 给你锋利的工具和钝的安全的工具，然后拒绝替你选择——取舍由你自己承担。

“if let 的一个分支产出一个值，另一个则完全从函数中返回。”

“One branch of the if let produces a value, and the other one returns from the function entirely.”

尖锐的诊断：问题不是行数，而是这两个分支不是同一种东西。不对称的控制流穿着对称的语法。

“它留在函数主体的“顺利路径”上”

“it stays on the “happy path” in the main body of the function”

所以 let...else 的存在，主要是为了压平缩进，并把失败放在边缘。一整个语法形式，因可读性而被辩护——对特性为什么被加进来，不寻常地坦率。

“编译器会确保你的函数只得到每个函数所期望类型的值。”

“The compiler will make certain your functions only get values of the type each function expects.”

本章结束时，把所有这些严格重新命名为一种服务。枚举加 match 不是限制——它们是你把领域的规则推进类型系统、并停止手动检查它们的办法。

“如果你想让一个函数或结构体之类的条目私有，就把它放进一个模块。”

“If you want to make an item like a function or struct private, you put it in a module.”

值得停下来的倒装措辞：私有性不是你加上的关键字，而是你把东西放进去的边界。模块是保密的单位。

“办公室经理可以看到并做他们所运营的餐厅里的一切”

“office managers can see and do everything in the restaurant they operate”

这个比喻在这里物有所值——不对称的可见性，作为规则感觉任意，作为组织架构图则显而易见。

“让模块公有，并不会让它的内容公有”

“making the module public doesn’t make its contents public”

这个两个错误的序列是有意的脚手架：它们让你失败两次，这样 pub 就不再感觉像一个魔法开关。门开了 ≠ 柜子开了。

“你不仅是作者，你还是一个客户！”

“not only are you the author, but you’re also a client!”

本章最好的 API 设计建议，被夹带在一个侧栏里。强迫二进制文件通过公共 API，是个结构性的把戏，而不是纪律上的。

“我们的偏好一般是指定绝对路径”

“Our preference in general is to specify absolute paths”

他们给出了推理——定义和调用处各自独立移动——而不只是一条规则。不过我要指出，super 后来削弱了它作为一概而论的默认值。

“厨师根据当季和库存里有什么，来决定搭配哪种水果”

“the chef decides which fruit accompanies the meal based on what’s in season and in stock”

这个比喻在这里物有所值：私有性不是官僚主义，而是调用者无权断言其值的那个字段。封装由领域的易变性来辩护。

“这个结构体需要提供一个公共的关联函数，来构造一个实例”

“the struct needs to provide a public associated function that constructs an instance”

悄悄地是这一节里最重要的一句话——一个私有字段，构造函数就成了必须的 API。私有性传播进设计，而不只是访问。

“枚举的变体如果不是公有的，枚举就不大有用”

“Enums aren’t very useful unless their variants are public”

所以这种不对称是务实的，而不是有原则的。Rust 的“默认私有”，在默认值只会令人烦恼的地方都有例外——诚实，但这意味着你要背，而不是推导。

“这种惯用法背后没有强烈的理由：只是已经出现的约定”

“There’s no strong reason behind this idiom: It’s just the convention that has emerged”

在一本语言书里，难得而令人钦佩的坦率。半页从清晰的角度为函数的惯用法辩护，然后结构体的惯用法根本没有得到论证——约定被承认为约定。

“我们可以用一种结构来编写我们的代码，而暴露另一种结构”

“we can write our code with one structure but expose a different structure”

这是本章真正的论点，迟到而低调：你在其中构建的模块树，和你发布的那一棵，是两个不同的产物。之前的一切只是机制。

“mod 不是你可能在其他编程语言里见过的“include”操作”

“mod is not an “include” operation that you may have seen in other programming languages”

直接瞄准 C 的习惯。声明一次，然后用路径指向它——文件不是意义的单位，树才是；文件名只需要与它保持一致。

“你的项目最终可能有许多名为 mod.rs 的文件，当你把它们同时打开时，可能会令人困惑”

“your project can end up with many files named mod.rs, which can get confusing when you have them open”

反对旧风格的决定性论证，是编辑器标签页的可读性。工具的人体工学，作为语言设计的压力——小，而完全真实。

“在这种情况下，指向第一个元素的引用将指向已被释放的内存。”

“In that case, the reference to the first element would be pointing to deallocated memory.”

这是连续性并不免费的真正原因。向量靠地址的不稳定，来为它的缓存友好付费。

“字符串是比许多程序员所认为的更复杂的数据结构”

“strings being a more complicated data structure than many programmers give them credit for”

诚实的诊断：Rust 没有让字符串变难，它只是不再隐藏它们一直都是这样。别的语言让你舒舒服服地继续错下去。

“我们为什么用对 s2 的引用，与我们使用 + 运算符时被调用的方法的签名有关”

“the reason we used a reference to s2, has to do with the signature of the method that’s called when we use the + operator”

可爱的祛魅：s1 + &s2 的不对称不是任意的语法，而是一个函数签名透了出来。读一读类型，怪异就消散了。

“看起来它在做大量的拷贝，但其实没有；这个实现比拷贝更高效”

“it looks like it’s making a lot of copies, but it isn’t; the implementation is more efficient than copying”

让 + 令人困惑的那个动作，恰恰是让它快的动作。人体工学被牺牲了，去换取一个你看不到的分配的复用。

“这里有六个 char 值，但第四个和第六个不是字母”

“There are six char values here, but the fourth and sixth are not letters”

这是教训落地的地方。char 不是一个字母——哪里都不是，从来不是。Rust 只是让你去看那道缝隙。

“Rust 不允许我们对 String 做索引来获得字符的最后一个原因是，索引操作被期望总是花常数时间（O(1)）”

“A final reason Rust doesn’t allow us to index into a String to get a character is that indexing operations are expected to always take constant time (O(1))”

注意论证类型的转变——从正确性转向性能契约。Rust 拒绝提供一个其代价会与它的语法不符的操作。

“所以，如果你真的需要用索引来创建字符串切片，Rust 要求你更具体一点。”

“If you really need to use indices to create string slices, therefore, Rust asks you to be more specific.”

不是禁止，而是要求承诺：范围仍然让你在字符中间切片，并在运行时 panic。具体性给你买到的是许可，而不是安全。

“end byte index 1 is not a char boundary; it is inside 'З' (bytes 0..2 of string)”

错误信息做着文档做不到的教学工作：它点出冒犯的字符及其字节跨度。Rust 的诊断是它教学法的一部分。

“从字符串中获取字形簇，如天城文，是复杂的，所以标准库没有提供这个功能。”

“Getting grapheme clusters from strings, as with the Devanagari script, is complex, so this functionality is not provided by the standard library.”

诚实，但注意它意味着什么：人类实际感知为“一个字母”的那一层，是 Rust 拒绝提供的唯一一层。默认的正确性，在用户的眼前戛然而止。

“它防止你在开发生命周期的后期，不得不处理涉及非 ASCII 字符的错误”

“it prevents you from having to handle errors involving non-ASCII characters later in your development life cycle”

整个取舍的论证，一个从句说完——痛苦被提前了，而不是被消除。值得问一问，在第8章感受到这种摩擦的初学者，是把它体验为预防，还是惩罚。

“在我们三个常用的集合中，这个是最少使用的，所以它没有被包含在 prelude 中自动引入作用域的特性里。”

“Of our three common collections, this one is the least often used, so it’s not included in the features brought into scope automatically in the prelude.”

难得一窥语言的人体工学是如何被配给的：prelude 是一场人气竞赛。use 那一行，是对多年前某人做出的判断的一种税。

“let score = scores.get(&team_name).copied().unwrap_or(0);”

读一个数字要三次方法调用——而本章在展示每个环节之后，才解释它。这是 Option 税对学习者变得可见的时刻。

“这种技术比我们自己写逻辑要干净得多，此外，它与借用检查器合作得也更好。”

“This technique is much cleaner than writing the logic ourselves and, in addition, plays more nicely with the borrow checker.”

第二个理由才是真正的理由。entry 的存在，是因为朴素的 contains_key 再 insert 的模式会借用两次；API 是由借用检查器塑造的，而不只是由品味。

“let count = map.entry(word).or_insert(0); *count += 1;”

两行完成单词计数，而 * 是整个教训：你持有一个指向映射内部的活指针，而编译器已经证明在此期间没有别人能碰它。

“为了更好的安全而付出的性能下降这个代价是值得的”

“the trade-off for better security that comes with the drop in performance is worth it”

一个被陈述为事实的价值判断——而且是个站得住脚的，因为另一种选择是一个远程攻击者把你的映射塌缩成链表。不过，“值得”是书在替你选择，而退出的办法被埋在后面。

“把字符串转换成 Pig Latin。每个单词的第一个辅音被移到末尾”

“Convert strings to Pig Latin. The first consonant of each word is moved to the end”

一个狡猾的练习：它看起来像个玩具，但“第一个辅音”迫使你去问，第一个字符究竟是什么——恰恰是这一段刚刚花了好几页搭起来的陷阱。

“程序使用的内存，随后需要由操作系统清理。”

“Memory that the program was using will then need to be cleaned up by the operating system.”

一次安静的坦白：操作系统才是真正的最后手段的垃圾回收器。Rust 的安全叙事倚靠一个它从不宣传的后盾。

“在 C 里，试图读取超出数据结构末尾的内容，是未定义行为。”

“In C, attempting to read beyond the end of a data structure is undefined behavior.”

这是本章修辞的铰链：panic 看起来强硬，直到你看到替代方案是无声的安全漏洞。崩溃被重新框定为一个特性。

“从顶部开始读，直到你看到你写的文件”

“start from the top and read until you see files you wrote”

到目前为止最实用的一句话，却被埋在段落中间。调试建议是社会性的：找到责任变成你的那一行。

“好多 match！”

“That’s a lot of match!”

作者们打破口吻，承认他们自己的例子令人不快——然后把解药推迟到第13章。在人体工学的捷径之前先教原语，是有意的，但这确实意味着读者对 Rust 错误处理的第一印象是“乏味”。

“大多数 Rustacean 选择 expect 而不是 unwrap”

“most Rustaceans choose expect rather than unwrap”

是文化说明，而不是语言规则。真正的内容是：expect 的信息，是写下你所押注的假设的地方，这样崩溃就把你的推理解释回给你。

“我们没有足够的信息，知道调用代码实际上想做什么”

“We don’t have enough information on what the calling code is actually trying to do”

传播的诚实理由：错误处理是关于谁持有上下文，而不是谁持有失败。把错误往上推，是对认知局限的承认。

“通过 from 函数，它定义在 From trait 里”

“go through the from function, defined in the From trait”

很容易略过，但这就是 ? 能扩展的原因。没有自动转换，这个运算符就只会在类型完全一致时才管用，整个人体工学上的胜利就会蒸发。

“fn read_username_from_file() -> Result<String, io::Error> { fs::read_to_string("hello.txt”

四份细心的脚手架清单塌缩成一行——而笑点是，标准库已经做了。一个狡猾的教训：最好的错误处理，往往是你没有写的代码。

“当然，使用 fs::read_to_string 并没有给我们机会解释所有的错误处理，所以我们先用了更长的办法。”

“Of course, using fs::read_to_string doesn’t give us the opportunity to explain all the error handling, so we did it the longer way first.”

难得一见，书承认了它自己教学上的编排。诚实，但也悄悄地承认，前面几页是演戏。

“你是在代表调用代码，做出一个情形不可恢复的决定”

“you’re making the decision that a situation is unrecoverable on behalf of the calling code”

这是整章的伦理核心：panic 是对别人的程序宣称权威。错误设计，作为一个谁来决定的问题。

“编译器还没有聪明到能看出这个字符串总是一个有效的 IP 地址”

“the compiler isn’t smart enough to see that this string is always a valid IP address”

注意负担落在谁身上——不是编译器的错，而是你要去写成文档。expect 的信息成了写给未来自己的便条，而不是运行时特性。

“违反契约总是表明调用方一侧的 bug，而且这不是你想让调用代码必须明确处理的那种错误”

“a contract violation always indicates a caller-side bug, and it’s not a kind of error you want the calling code to have to explicitly handle”

尖锐的区分终于被说清了：Result 是为世界出错，panic 是为程序员出错。本章前面的一切，都是在绕着这条线打转。

“试图向你的函数传“什么也没有”的代码甚至无法编译，所以你的函数不必在运行时检查那种情形。”

“Code trying to pass nothing to your function won’t even compile, so your function doesn’t have to check for that case at runtime.”

真正的笑点——最好的错误处理，是你使之无法表示的错误。类型作为只需付一次费的检查。

“重要的是，value 字段是私有的，这样使用 Guess 结构体的代码就不被允许直接设置 value”

“It’s important that the value field be private so that code using the Guess struct is not allowed to set value directly”

这里的私有性不是为了隐藏，而是承重的：没有它，不变量就蒸发了。new 这个单一的咽喉点，是使这个类型有意义的东西。

“Rust 也从可执行文件返回整数，以与这个约定兼容。”

“Rust also returns integers from executables to be compatible with this convention.”

一个小小的提醒：即使是一门对类型如此一丝不苟的语言，在边界上也要向一个几十年前的 C 习惯鞠躬。

“T 是 type 的缩写，是大多数 Rust 程序员的默认选择。”

“Short for type, T is the default choice of most Rust programmers.”

半段话谈一个命名约定。值得——一旦你内化了 T 只是一个像 x 那样的参数名，泛型就不再像巫术。

“largest 的函数体并不适用于 T 可能是的所有可能类型”

“the body of largest won’t work for all possible types that T could be”

这是整个哲学，一行说完：一个泛型函数必须针对每一个可能的 T 来检查，而不只是你碰巧调用它时用的那些。这就是 trait 约束之所以存在的原因——C++ 模板则在实例化时失败。

“如果你发现你的代码里需要很多泛型类型，这可能表明你的代码需要重构成更小的部分。”

“If you’re finding you need lots of generic types in your code, it could indicate that your code needs restructuring into smaller pieces.”

难得一见的品味而不是机制的时刻。编译器不会在 Point<T,U,V,W> 处阻止你；只有判断力能。

“T 不是 f32 类型的 Point<T> 的其他实例，将没有定义这个方法”

“other instances of Point<T> where T is not of type f32 will not have this method defined”

方法有条件地存在于类型参数之上，是一个与类继承真正不同的心智模型——能力附着在一个形状上，而不是一个对象上。这一句话的分量，比它所处的位置所暗示的更重。

“我们使用泛型不付运行时代价”

“we pay no runtime cost for using generics”

真，却悄悄地不完整：代价转移到了编译时间和二进制体积上。单态化是个取舍，而不是免费的午餐——书只兜售了它的一面。

“用户必须把 trait 和类型一起引入作用域”

“the user must bring the trait into scope as well as the types”

日常的摩擦点。一个方法可以存在于你面前的值上，却仍然不可见——这也是使以后给别人的类型添加方法变得安全的原因。

“这条规则确保别人的代码不会破坏你的代码，反之亦然”

“This rule ensures that other people’s code can’t break your code and vice versa”

孤儿规则被框定为礼貌，但它其实是关于解析的全局唯一性。注意书跳过的代价：你不能把 Display 加到 Vec 上，所以你把它包进一个新类型——人人都碰到的摩擦。

“注意，不可能从一个覆盖的实现中调用默认实现”

“Note that it isn’t possible to call the default implementation from an overriding implementation”

被一句平淡的话丢了出来，但这是与面向对象继承的真正不对称——这里没有 super.summarize()。Trait 给你默认值，而不是一个父类。

“一个 trait 可以提供许多有用的功能，而只要求实现者指定其中的一小部分”

“a trait can provide a lot of useful functionality and only require implementors to specify a small part of it”

这是这一节实际的设计教训：挑选最小的必需核心，推导其余。summarize_author 就是那道接缝。

“如果我们想让这个函数允许 item1 和 item2 有不同的类型，使用 impl Trait 是合适的”

“Using impl Trait is appropriate if we want this function to allow item1 and item2 to have different types”

好时刻——书不再把 impl Trait 仅仅称为“语法糖”，而是表明这两种形式实际上意味着不同的东西。改变语义的糖，不是糖。

“由于 impl Trait 语法在编译器中的实现所受的限制，不被允许”

“isn’t allowed due to restrictions around how the impl Trait syntax is implemented in the compiler”

难得诚实的耸肩：这不是一条原则，而是一个单态化的事实。impl Trait 是在编译期选定的一个具体类型；分支则需要 vtable。

“但 Rust 把这些错误移到编译期，这样我们在代码甚至还能运行之前，就被迫修复问题”

“But Rust moves these errors to compile time so that we’re forced to fix the problems before our code is even able to run”

整章的论点，终于被陈述出来了。而点睛之笔是下一句：没有运行时检查，意味着安全是免费的。

“生命周期标注不改变任何引用能活多久。”

“Lifetime annotations don’t change how long any of the references live.”

解锁生命周期的那一句话。初学者把 'a 读作“让它活得更久”；它是一种描述，而不是命令——更接近类型，而不是指令。

“我们也不知道，因为这个函数体中的 if 块返回对 x 的引用，而 else 块返回对 y 的引用”

“we don’t know either, because the if block in the body of this function returns a reference to x and the else block returns a reference to y”

可爱的教学法——编译器的无知就是你的无知。这个错误不再感觉像官僚主义。

“泛型生命周期 'a 将得到具体的生命周期，等于 x 和 y 的生命周期中较小的那个”

“the generic lifetime 'a will get the concrete lifetime that is equal to the smaller of the lifetimes of x and y”

'a 不是 x 的生命，也不是 y 的——而是交集。一个标签，把两个不相等的作用域坍缩到它们的重叠部分，这就是为什么这个契约是健全的，却是保守的。

“作为人类，我们可以看着这段代码，看出 string1 比 string2 长”

“As humans, we can look at this code and see that string1 is longer than string2”

诚实的承认：编译器拒绝实际上安全的代码。生命周期是一种保守的近似，而不是真相——当你在和借用检查器搏斗时，值得记住这一点。

“最好的修复是返回一个拥有所有权的数据类型，而不是引用”

“the best fix would be to return an owned data type rather than a reference”

真正的教训藏在一句随口的话里：当生命周期变得不可能时，答案通常是所有权，而不是更聪明的标注。再多的 'a 也修不了一个设计问题。

“每个测试都在一个新线程里运行，当主线程看到一个测试线程已经死掉，这个测试就被标记为失败。”

“Each test is run in a new thread, and when the main thread sees that a test thread has died, the test is marked as failed.”

一句话解释了整个机制：“失败”不是框架定义的概念，只是一个死掉的线程。以 panic 为协议。

“在 Rust 里，它们叫做 left 和 right，而我们指定期望值和代码产生的值的顺序无关紧要”

“in Rust, they’re called left and right, and the order in which we specify the value we expect and the value the code produces doesn’t matter”

说得过去——但 expected/actual 不是吹毛求疵，而是文档。对称的命名意味着失败信息无法告诉你，哪个数字是愿望，哪个是事实。

“我们很确定问候语开头的 Hello 文字会改变”

“we’re pretty sure the Hello text at the beginning of the greeting will change”

藏在一个宏演示里的真正有价值的教训：在你所相信的需求层面写断言，而不是在你碰巧拥有的字符串层面。

“如果函数里的代码 panic，测试就通过；如果函数里的代码没有 panic，测试就失败。”

“The test passes if the code inside the function panics; the test fails if the code inside the function doesn’t panic.”

光秃秃的 should_panic 危险地粗糙——任何 panic，来自任何一行，出于任何理由，都算作成功。一个会 panic 的笔误也能通过这个测试。

“即使测试因与我们预期不同的原因而 panic，should_panic 测试也会通过。”

“A should_panic test would pass even if the test panics for a different reason from the one we were expecting.”

诚实的承认：一个通过的测试可能在对你撒谎。整个虚假信心的类型，一句话说完。

“你选择指定什么，取决于 panic 信息中有多少是独特的或动态的，以及你希望你的测试有多精确。”

“What you choose to specify depends on how much of the panic message is unique or dynamic and how precise you want your test to be.”

没有给出规则，只是把一个取舍交还给你。匹配过于精确，会使测试在措辞改变时就坏掉；过于宽松，会让 bug 漏过。

“要断言一个操作返回 Err 变体，不要对 Result<T, E> 的值使用问号运算符。相反，使用 assert!(value.is_err())。”

“To assert that an operation returns an Err variant, don’t use the question mark operator on the Result<T, E> value. Instead, use assert!(value.is_err”

容易绊倒：? 传播的是 Err，并且让恰恰想要它的那个测试失败。便利的运算符颠倒了你的意图。

“不是因为代码不正确，而是因为测试在并行运行时彼此干扰了”

“not because the code is incorrect but because the tests have interfered with each other while running in parallel”

并行是默认的，所以这种失败模式也是默认的。Rust 保护你程序里的共享状态，然后交给你一个完全没有保护的共享文件系统。

“默认情况下，如果一个测试通过，Rust 的测试库会捕获任何打印到标准输出的东西。”

“By default, if a test passes, Rust’s test library captures anything printed to standard output.”

悄悄解释了你的调试 println! 为什么消失了——也是为什么那么多人为了看到输出，而求助于一个故意失败的断言。

“我们不能用这种办法指定多个测试的名字；只有给 cargo test 的第一个值会被使用。”

“We can’t specify the names of multiple tests in this way; only the first value given to cargo test will be used.”

悄悄忽略多余的参数，而不是报错，是你在纳闷为什么一半的测试没有运行之后才会发现的那类事。

“无论你坚持哪种测试意识形态，Rust 的私有性规则确实允许你测试私有函数。”

“Regardless of which testing ideology you adhere to, Rust’s privacy rules do allow you to test private functions.”

一门语言做出了立场中立的选择——模块的子级能看到祖先，所以这是从模块系统中掉出来的，而根本不是一个测试方面的决定。

“注意，如果某一节中有任何测试失败，后面的几节将不会运行。”

“Note that if any test in a section fails, the following sections will not be run.”

在你断定集成测试没问题之前，值得记住这一点——它们可能根本没有被执行过。

“我们会在测试输出里看到 common.rs 文件的一个新小节，即使这个文件不包含任何测试函数”

“we’ll see a new section in the test output for the common.rs file, even though this file doesn’t contain any test functions”

一文件一 crate 的规则在这里泄漏了：一个助手模块被当作测试目标。第7章的直觉在积极地误导你。

“我们不创建 tests/common.rs，而是创建 tests/common/mod.rs”

“instead of creating tests/common.rs, we’ll create tests/common/mod.rs”

修复是一个文件名，而不是代码。Rust 在这里的约定悄悄地是承重的——目录形式是说“这不是测试”的唯一办法。

“这是 Rust 也理解的较旧的命名约定”

“This is the older naming convention that Rust also understands”

“较旧的”在做道歉的工作。第7章告诉我们偏好新风格；而在这里，被弃用的形式是唯一管用的形式。遗留的东西被保留着，因为它碰巧承载了含义。

“tests 目录子目录中的文件不会被编译成单独的 crate”

“Files in subdirectories of the tests directory don’t get compiled as separate crates”

这才是真正的规则——上面的一切都是它的后果。书先说症状，把机制埋在距离结尾一句话的地方。

“二进制 crate 是意在自己独立运行的”

“binary crates are meant to be run on their own”

一个打扮成自然事实的设计决定。它是编译器的策略，而整个 src/main.rs 很薄的模式，就是为绕过它而存在的。

“虽然你在 Rust 里很少需要标注类型，collect 却是你经常需要标注的一个函数”

“Although you very rarely need to annotate types in Rust, collect is one function you do often need to annotate”

揭示机制的例外：推断从值向外流，但 collect 对它的输出是泛型的，所以上游没有东西可供推断。值得停下来想想。

“一首艾米莉·狄金森的诗，会很合适！”

“an Emily Dickinson poem that will work well!”

选“I'm Nobody! Who are you?”给一个搜词出现处的工具当测试数据，比作者承认的还要好笑——而且它真的有你需要的重复词。

“经常检查进度是好的，这有助于在问题出现时找出原因。”

“It’s good to check your progress often, to help identify the cause of problems when they occur.”

这里教的方法不是模块化，而是步子的大小。小的重构让归咎的范围保持很小——这才是真正可迁移的技能。

“我们返回了一个元组，却又立刻把这个元组拆成各个部分。这表明也许我们还没有找到正确的抽象”

“we’re returning a tuple, but then we immediately break that tuple into individual parts again. This is a sign that perhaps we don’t have the right abstraction yet”

本章最好的一句：一种具体的、可检查的味道，而不是对好设计含糊的诉求。先打包再立刻拆包，意味着这个分组从来不是真的。

“与其第一遍就想把代码过度优化，不如有一个有点低效的能跑的程序。”

“It’s better to have a working program that’s a bit inefficient than to try to hyperoptimize code on your first pass.”

教学上慷慨，也化解了真正的隐患——初学者把 Rustacean 对克隆的羞辱当成禁令，吓得不敢动。第13章还是会悄悄把这些克隆删掉。

“我们还要把函数名从 new 改成 build，因为许多程序员期望 new 函数永不失败”

“We’re also going to change the function name from new to build because many programmers expect new functions to never fail”

一条只靠期望维持的约定——编译器毫不在乎。命名，是 API 传达“这可能失败”的唯一通道。

“对编程问题而言，调用 panic! 比对用法问题更合适”

“A call to panic! is more appropriate for a programming problem than a usage problem”

干净的坐标轴：panic 用于我代码里的 bug，Result 用于你输入里的错误。我读过的几乎每个糟糕的 Rust 命令行工具，都把这个弄反了。

“因为你无法直接测试 main 函数，这种结构让你能测试程序的全部逻辑”

“Because you can’t test the main function directly, this structure lets you test all of your program’s logic”

所以 main.rs/lib.rs 的拆分不是审美——是可测试性迫使出一种架构。不可测试的区域被缩小，直到读一遍就足以证明它。

“我们不再得到所有那些额外的输出”

“we no longer get all the extra output”

真正的教训藏在 diff 里：panic! 把实现细节泄漏给用户。退出码和朴素的消息是一条边界，不是一种方便。

“表明我们调用 run 只是为了它的副作用的惯用方式”

“the idiomatic way to indicate that we’re calling run for its side effects only”

Ok(()) 是类型系统承认有些函数的存在，只是为了扰动世界。诚实的丑陋。

“注意，帮助文本建议给所有参数和输出类型指定同一个生命周期参数，这是不对的！”

“Note that the help text suggests specifying the same lifetime parameter for all the parameters and the output type, which is incorrect!”

罕见而宝贵：书告诉你，编译器的建议是错的。能编译 ≠ 正确——生命周期编码了机器推断不出的意图。

“结果不是边找到边打印的；我们会讨论用迭代器来修复这一点的一种可能办法”

“results aren’t printed as they’re found; we’ll discuss a possible way to fix this using iterators”

一个有意埋下的缺陷，被标出而不是隐藏。靠延期的债来教学——但读到这里就停的读者，发出去的是慢的版本。

“把 search 函数定义成总是返回一个空向量”

“defining the search function to always return an empty vector”

TDD 里最好笑的诚实时刻：写一个谎，只为改变失败的颜色。panic 式失败和断言式失败，是不同等级的认知。

“我们加了一行新文本：“Duct tape.”

“We’ve added a new line with the text "Duct tape.”

在碰新代码之前，先给旧测试加一个擦边的反例——这点小小的纪律，防止不区分大小写悄悄吃掉区分大小写。

“虽然 to_lowercase 会处理基本的 Unicode，它并不是 100% 准确的。”

“While to_lowercase will handle basic Unicode, it won’t be 100 percent accurate.”

一句话的活板门。教程里每一条“真实应用”的警告，都是某个人会原样发出去的 bug。

“所以我们用 is_ok 检查，而不用 unwrap、expect，或我们见过的 Result 上任何其他方法”

“so we’re checking is_ok rather than using unwrap, expect, or any of the other methods we’ve seen on Result”

漂亮：方法的选择，由你真正需要知道的东西来辩护。是存在与否，不是值。不过这意味着 IGNORE_CASE=0 或 IGNORE_CASE=false 仍会把它打开——一个书没有指出的真瑕疵。

“决定是命令行参数还是环境变量应该优先”

“Decide whether the command line argument or the environment variable should take precedence”

这个练习交给你的是一个真正的设计判断，而不是语法操练。顺带一提，约定是：显式的标志胜过环境里的变量。

“这些类型随后被锁进 example_closure 中的闭包”

“Those types are then locked into the closure in example_closure”

“锁”是诚实的词。推断不是泛型——闭包得到一个类型，由首次使用决定。很容易把定义处的灵活误当成多态。

“闭包将根据函数体对被捕获的值做什么，来决定使用其中哪一个。”

“The closure will decide which of these to use based on what the body of the function does with the captured values.”

注意这个口误：“函数的主体”应当是闭包。很小，但说明问题——作者们自己也一直在这两个概念之间滑动。

“我们在调用闭包之后不再使用它，所以可变借用结束。”

“We don’t use the closure again after the closure is called, so the mutable borrow ends.”

借用的生命周期由最后一次使用而不是作用域设定。这是安静的 NLL 规则在做工作，而书拒绝点它的名。

“试着去掉 move 关键字，或者在定义闭包之后在主线程中使用 list，看看你会得到什么编译器错误！”

“Try removing the move keyword or using list in the main thread after the closure is defined to see what compiler errors you get!”

书第三次把教训外包给一个练习。有效的教学法，但这也意味着错误信息——这里真正的老师——留在了书页之外。

“闭包会以累加的方式，自动实现这些 Fn trait 中的一个、两个或全部三个”

“Closures will automatically implement one, two, or all three of these Fn traits, in an additive fashion”

值得坐下来想想：这些 trait 形成了一个克制的层次结构。闭包对它的捕获做得越少，赢得的 trait 就越多。能力源于自我克制。

“因为所有闭包都实现 FnOnce，unwrap_or_else 接受所有三种闭包，并尽可能地灵活。”

“Because all closures implement FnOnce, unwrap_or_else accepts all three kinds of closures and is as flexible as it can be.”

藏在库签名里的设计教训：要求你能遵守的最弱的约束。FnOnce 不是对调用者的限制，而是被调用者的承诺。

“这是一种牵强、绕弯子的（而且行不通的）计数办法”

“This is a contrived, convoluted way (that doesn’t work) to try to count”

书在句子中间为自己的例子道歉。诚实，却削弱了教训——读者可能把这个错误当作愚蠢设定的产物而打发掉，而不是一个真正的约束。

“在 Rust 中，迭代器是惰性的，意思是在你调用消耗迭代器的方法之前，它们不起任何作用”

“In Rust, iterators are lazy, meaning they have no effect until you call methods that consume the iterator”

一个词，“惰性”，悄悄地把迭代从一个循环，重新框定为一个可以传来传去的值。回报在本章后面到来；基础工作在这里。

“我们在使用 for 循环时不需要让 v1_iter 可变，因为循环取得了 v1_iter 的所有权，并在幕后使它可变。”

“We didn’t need to make v1_iter mutable when we used a for loop, because the loop took ownership of v1_iter and made it mutable behind the scenes.”

for 循环一直在悄悄做脏活。很高兴看到语法糖被剥开——可变并没有消失，只是被藏起来了。

“note: iterators are lazy and do nothing unless consumed”

一个做教学的编译器警告。语言靠拒绝让你悄悄浪费惰性，来教授惰性。

“因为 map 取一个闭包，我们可以指定我们想对每一项执行的任何操作。”

“Because map takes a closure, we can specify any operation we want to perform on each item.”

这是本章实际的论点：闭包是可定制的洞，迭代器是可复用的框架。标题的两半终于咔嗒一声合上了。

“去掉可变状态，也许能实现让搜索并行进行的未来改进”

“Removing the mutable state might enable a future enhancement to make searching happen in parallel”

为函数式风格所做的真正论证不是优雅，而是不可变性是并行的先决条件。Rayon 被预告了，却没有点名。

“结果将在每个匹配的行被找到时打印出来，因为 run 函数里的 for 循环能够利用迭代器的惰性”

“the results will be printed as each matching line is found because the for loop in the run function is able to take advantage of the laziness of the iterator”

惰性从一个烦人的警告，变成了一个可观察的特性——到第一个结果的延迟。同一个性质，相反的价值取向，相隔三十段。

“你确实用到的，你手写也不可能写得更好。”

“What you do use, you couldn’t hand code any better.”

借用斯特劳斯特鲁普的标准是个精明的修辞动作——它承认基准测试的论证很弱，转而倚靠一条借来的原则。

“创建一个有用的公共 API 结构，与其说是科学，不如说是艺术”

“Creating a useful public API structure is more an art than a science”

对一本语言书来说，这是不寻常的诚实。这里别的一切都有正确答案；API 的形状没有。

“允许删除版本，会使实现那个目标变得不可能。”

“Allowing version deletions would make fulfilling that goal impossible.”

永久性是一次有意的取舍：每个下游构建都继续能用，而你永远无法收回一个错误。left-pad 是这一段里的幽灵。

“例如，它无法删除不小心上传的秘密。”

“It cannot, for example, delete accidentally uploaded secrets.”

直白而受欢迎——yank 是路由的改变，不是抹除。值得一提的是，本章用不同的话说了两遍，一次关于令牌，一次关于代码。

“每个 crate 都得重新编译工作空间里其他每个 crate”

“each crate would have to recompile each of the other crates in the workspace”

共享的 target 不是为了整洁，而是缓存复用。这个解释为一个否则看起来令人意外的布局辩护。

“Cargo 并不假定工作空间里的 crate 会彼此依赖”

“Cargo doesn’t assume that crates in a workspace will depend on each other”

同处一地不是依赖。让依赖图保持显式，而不是随环境而来——与 Rust 一贯拒绝推断关系的做法一致。

“这确保了所有 crate 都使用所有依赖的同一个版本。”

“This ensures that all crates are using the same version of all dependencies.”

单一的锁文件，就是工作空间全部的哲学要点——一份一致性保证，靠一个文件买来。这里其余的一切都是管道。

“我们不能在工作空间里的其他 crate 里使用它，除非我们也把 rand 加进它们的 Cargo.toml 文件”

“we can’t use it in other crates in the workspace unless we add rand to their Cargo.toml files as well”

漂亮的不对称：共享的是版本，不共享的是可见性。锁文件是公有的，清单保持私有——依赖声明仍是一种同意的行为。

“Cargo 会解析它们每一个，但仍会尽量解析出尽可能少的版本。”

“Cargo will resolve each of them but will still try to resolve as few versions as possible.”

一次安静的承认：上面的承诺有限度。本章卖的是统一性，然后又承认它只是尽力而为。

“最后一节表明，在 add_one crate 里一个文档测试都没有找到”

“the last section shows that zero documentation tests were found in the add_one crate”

靠空输出来教学——带读者走过三段什么都没发生的小节。乏味，但这是你学会读懂 cargo 的布局、而不是怕它的办法。

“工作空间里的每个 crate 都需要单独发布”

“each crate in the workspace will need to be published separately”

工作空间是开发时的一个虚构。Crates.io 从来看不到它。在你围绕它设计十个 crate 的单体仓库之前，值得知道这一点。

“如果你的 $PATH 里有一个名为 cargo-something 的二进制，你就可以把它当作 Cargo 子命令来运行”

“If a binary in your $PATH is named cargo-something, you can run it as if it were a Cargo subcommand”

靠命名约定扩展——没有插件 API，没有注册表，只有一个前缀。最便宜的可扩展性，也是最耐久的。

“Rust 的标准库小而稳定，但 crate 很容易分享”

“Rust’s standard library is small and stable, but crates are easy to share”

收尾那句把一个限制重新框定为一个策略：std 库保持单薄，是因为 crates.io 可以走得更快。整章都是在为这桩交易辩护。

“这个实现现在更像是把各项并排放置，而不是一个套在另一个里面”

“this implementation is now more like placing the items next to one another rather than inside one another”

到目前为止最好的一句话。间接引用被重新框定为空间上的——嵌套变成了相邻，无穷就塌缩了。

“我们的版本不会把它的数据存储在堆上。”

“Our version will not store its data on the heap.”

坦率地承认 MyBox 只是名字上的盒子。它干净地隔离了 Deref，却悄悄地教着，“智能指针”是关于行为的，而不是位置。

“值将被从 self 里移出”

“the value would be moved out of self”

这是 Deref 不再是语法糖、撞上所有权的地方。括号外面多出来的 * 不是冗余——而是借用检查器透出来了。

“所以利用解引用强制转换，没有运行时惩罚！”

“so there is no runtime penalty for taking advantage of deref coercion!”

零成本的说法落地了，但值得注意那个不是运行时的隐藏成本：可读性。强制转换让类型在你底下悄悄变换。

“把不可变引用转换成可变引用，要求最初的不可变引用是对该数据唯一的不可变引用”

“Converting an immutable reference to a mutable reference would require that the initial immutable reference is the only immutable reference to that data”

这个不对称是缩影中的整个借用系统：你总是可以削弱一个保证，永远无法凭空制造一个。

“你仍然不会泄漏资源！”

“you still won’t leak resources!”

欢快，但夸大了——Drop 在作用域退出时运行，而引用循环（这一章本身就会引入）欣然泄漏。书在开一张 Rc/RefCell 会退回的支票。

“变量按创建的相反顺序被丢弃，所以 d 在 c 之前被丢弃。”

“Variables are dropped in the reverse order of their creation, so d was dropped before c.”

栈的纪律在可观察的输出中浮现。悄悄地，这就是析构函数可以安全地引用在它们之前创建的东西的原因。

“Rust 不让我们显式调用 drop，因为 Rust 仍会在 main 的末尾自动对该值调用 drop。”

“Rust doesn’t let us call drop explicitly, because Rust would still automatically call drop on the value at the end of main.”

优雅：这个禁令不是说教式的，而是算术。而 drop(c) 之所以管用，只因为它取得了所有权——移动才是取消之后调用的东西。书从未把这一点完全大声说出来。

“把 Rc<T> 想象成家庭房里的一台电视机。”

“Imagine Rc<T> as a TV in a family room.”

这个类比是温暖的，却有漏洞——电视机没有“最后一个人必须离开”的概念。不过，“骚乱”是对释放后使用的一个不错的名字。

“我们就是在指明，list 中的每个元素都至少活得和整个 list 一样久”

“we would be specifying that every element in the list will live at least as long as the entire list”

这才是使用 Rc 的真正论证：不是生命周期失败了，而是它们要求你对程序结构做出一个你不总能做出的承诺。

“Rust 的约定是在这种情形下使用 Rc::clone”

“Rust’s convention is to use Rc::clone in this case”

一个纯粹为了让成本对读者清晰可读而存在的约定。难得的例子，风格规则服务于性能评审而不是美学。

“我们不必调用一个函数来减少引用计数”

“We don’t have to call a function to decrease the reference count”

在这里，本章的两个 trait 终于咬合了——Drop 是 Rc::clone 看不见的另一半。按这个顺序给它们排序，是个不错的结构性回报。

“这个模式在数据结构内部使用 unsafe 代码，来弯曲 Rust 通常的规则”

“the pattern uses unsafe code inside a data structure to bend Rust’s usual rules”

Rust 中的安全原来不是 unsafe 的缺席，而是它的封闭——有人审计过一次，这样你就永远不必审计。

“如果 Rust 拒绝一个正确的程序，程序员会感到不便，但不会发生任何灾难性的事情”

“if Rust rejects a correct program, the programmer will be inconvenienced, but nothing catastrophic can occur”

错误的不对称被直白地陈述——这是编译器的整个伦理，比旁边点名停机问题更有价值。

“Messenger trait 有一个名为 send 的方法，它接受对 self 的不可变引用”

“the Messenger trait has one method called send that takes an immutable reference to self”

陷阱在这里设下，而书知道：&self 对真正的发送者是正确的，对记录器则是不可能的。RefCell 的用例，是作为一个你无法控制的接口而到来的。

“我们不想仅仅为了测试而改动 Messenger trait。”

“We do not want to change the Messenger trait solely for the sake of testing.”

真正的约束是设计纪律，而不是编译器。注意书悄悄拒绝了编译器自己的建议——难得一见的时刻，工具对意图是错的。

“代码带着信息 already borrowed: BorrowMutError 而 panic 了”

“the code panicked with the message already borrowed: BorrowMutError”

上面的实际输出说的是“RefCell already borrowed”——文字和记录不一致。工具链信息变化留下的一道接缝。

“当 Rust 程序的主线程结束时，所有派生出来的线程都会被关停。”

“when the main thread of a Rust program completes, all spawned threads are shut down”

一个伪装成演示的竞态条件——这个例子的魅力在于，它的输出故意不可靠。

“一些小细节，比如在哪里调用 join，会影响你的线程是否同时运行。”

“Small details, such as where join is called, can affect whether or not your threads run at the same time.”

两个看上去一模一样的程序，并发行为却完全不同。行的顺序现在就是语义。

“move 关键字覆盖了 Rust 保守的借用默认值；它并不让我们违反所有权规则。”

“The move keyword overrides Rust’s conservative default of borrowing; it doesn’t let us violate the ownership rules.”

到目前为止最好的一句话：move 是在选择由哪一条规则来约束你，而不是一个逃生出口。初学者总把它误读成后者。

“不要通过共享内存来通信；而要通过通信来共享内存。”

“Do not communicate by sharing memory; instead, share memory by communicating.”

借自 Go，但 Rust 真能把它落实——编译器让这句口号具有约束力，而不只是一种愿景。

“我们的并发错误造成了一个编译期错误。”

“Our concurrency mistake has caused a compile-time error.”

这一行就是整章：著名的数据竞争坍缩成了一个普通的移动错误。不需要任何新机制。

“这正是并发既有趣又困难的原因。”

“This is what makes concurrency interesting as well as difficult.”

本章里唯一一句承认这些保证有下限的话：Rust 解决的是内存安全，而不是非确定性。交错执行仍然得由你自己来推理。

“不要通过共享内存来通信。”

“Do not communicate by sharing memory;”

作为挑衅被引了出来，随后又悄悄放过——本章余下的篇幅，教的恰恰是这句口号所警告的东西。

“如果一位小组讨论嘉宾说完话后忘了把麦克风交出去，其他人就都没法发言了。”

“If a panelist forgets to hand the microphone off when they’re finished with it, no one else is able to speak.”

好比喻，而且注意它换来了什么：失败模式被说成是忘记，而这恰恰是 Drop 消灭掉的那种失败。这个类比是为了让下一页看起来像一场营救而造的。

“多亏了 Rust 的类型系统和所有权规则，你不可能把加锁和解锁搞错”

“thanks to Rust’s type system and ownership rules, you can’t get locking and unlocking wrong”

说过头了，而本章自己也知道——二十段之后，死锁就被承认了。你不可能忘记解锁；但你完全可以加错锁。

“m 的类型是 Mutex<i32>，而不是 i32，所以必须调用 lock 才能使用里面的那个 i32 值。”

“The type of m is Mutex<i32>, not i32, so we must call lock to be able to use the i32 value.”

这才是真正的机制，而且平淡得几乎无聊：让数据除了通过那道门之外根本够不着。安全来自类型管道，而不是纪律。

“我们再次编译，得到了……不一样的错误！编译器教了我们很多东西”

“Once again, we compile and get… different errors! The compiler is teaching us a lot”

教学法就是设计上的论点：三次刻意的失败带你从移动错误走到 Send，再走到 Arc。把错误安排成课程，由编译器当老师。

“线程安全是有性能代价的，你只想在真正需要的时候才付这个代价”

“thread safety comes with a performance penalty that you only want to pay when you really need to”

对“为什么不把一切都做成原子的”这个问题的老实回答——也是 Rc 和 Arc 同时存在、而不是只有一个安全默认选项的原因。零成本意味着由你选择要不要付这份成本。

“任何类型 T，只要 &T（T 的不可变引用）实现了 Send，T 就实现了 Sync”

“any type T implements Sync if &T (an immutable reference to T) implements Send”

优雅的化简：共享被定义成发送一个引用，所以一个原语就涵盖了两者。这也是 RefCell 不行的原因——它在运行时的借用计数器，不能安全地把引用发送出去。

“我们到目前为止谈过的几乎每一项并发特性，都属于标准库，而不是语言”

“almost every concurrency feature we’ve talked about so far in this chapter has been part of the standard library, not the language”

真正的论点，留到了最后。语言只贡献了 Send 和 Sync；其余一切都是库，而且可以由你来写。很薄的内核，可扩展的安全。

“一旦你的代码编译通过，就可以放心，它会在多个线程上愉快地运行”

“Once you get your code to compile, you can rest assured that it will happily run on multiple threads”

本章自己先前的但书——非确定性、死锁、逻辑错误——让“放心”这个落脚点显得太舒服了。无畏的是数据竞争，而不是并发。

“当你对一个项目感到厌倦或卡住时，就切换到另一个”

“when you get bored or stuck on one project, you switch to the other”

这个类比很讨喜，但偷偷塞进了主观意愿。运行时不会厌倦；它只在你写下的 await 点上切换。这个差距后面会变得重要。

“现在你的并发工作也变成串行了。”

“Now your concurrent work has also become serial.”

悄悄地成了这一节最有用的一句：并发不是工具的属性，而是依赖关系的属性。再多的 await 语法也救不了你的真实依赖。

“Rust 里的 future 是惰性的：在你用 await 关键字要求它们之前，它们什么都不做”

“futures in Rust are lazy: they don’t do anything until you ask them to with the await keyword”

这是与 JS 真正的分歧，作者两次强调是对的。JS 的 promise 已经在运行了；Rust 的 future 是一份没人下厨的食谱。

“写一个 async fn，等同于写一个返回该返回类型的 future 的函数”

“writing async fn is equivalent to writing a function that returns a future of the return type”

脱糖是这一章里最体贴的东西——它把异步从一个魔法关键字，变成了一个你可以推理的类型层面的事实。

“程序的 main 函数可以初始化一个运行时，但它本身不是运行时。”

“A program’s main function can initialize a runtime, but it’s not a runtime itself.”

对一个看似武断的编译器错误，这是个优雅的回答。Rust 拒绝捆绑运行时是一种关于嵌入式目标的哲学立场，代价是样板代码。

“这是一台看不见的状态机，就好像你写了这样一个枚举”

“This is an invisible state machine, as if you’d written an enum like this”

手写的枚举是本章最好的教学装置。原本你后面会撞上的借用错误，一下子变得可以预料，而不再神秘——状态必须持有你的引用。

“Either 里没有内置成功或失败的概念”

“there is no notion of success or failure baked into Either”

API 设计上很克制：一场竞速里没有哪个输家配得上叫错误。用 Result 就会把一个价值判断强加给一个时间上的事实。

“这是因为 trpl::join 函数是公平的，也就是说，它检查每个 future 的次数相同”

“That is because the trpl::join function is fair, meaning it checks each future equally often”

整个对比真正的回报在这里：确定性。线程把调度交给操作系统；异步把调度交给一个你可以真正选择、也可以推理的运行时。

“更大的区别在于，我们不需要再派生另一个操作系统线程”

“The bigger difference is that we didn’t need to spawn another operating system thread”

本章悄悄拆了它刚教给你的那个例子的台。spawn_task 是教学用的脚手架，不是推荐做法。

“我们不 await send 调用，因为它不会阻塞。它也不需要这样做，因为我们往里发送的这个通道是无界的”

“we don’t await the send call, because it doesn’t block. It doesn’t need to, because the channel we’re sending it into is unbounded”

注意这条因果链：无界，所以 send 是同步的。有界通道会迫使 await——也就带来背压。一个很大的设计后果，被塞进了一个从句里。

“这个块无法结束，因为它在阻塞等待 trpl::join 完成，这又把我们带回了这份清单的开头。”

“The block can’t end because it is blocked on trpl::join completing, which takes us back to the top of this list.”

这一段里写得最好的地方——一个八步的推理绕回了自己，于是行文本身就字面意义上演出了它所描述的死锁。

“关键在于 future 被 await 的顺序，而不是它们被创建的顺序。”

“The key is the order in which the futures are awaited, not in which they’re created.”

这是该纹在读者身上的一句话。future 在被 await 之前是惰性的——创建的顺序只是记账，而这恰恰是从急切的 promise 转过来的人容易栽跟头的地方。

“一个 future 饿死了其他 future”

“one future starving other futures”

对协作式调度的老实自白：没有抢占，意味着每个 await 点都是你对同伴许下的承诺，而漏掉一个，就是编译器抓不到的背叛。

“像 sleep 所用的那种计时器，其粒度往往有限”

“timers such as the one used by sleep often have limits on how granular they can be”

漂亮的一笔——把 sleep 当作让出的招数，不只是含糊，而且是可测量地错误。意图和性能在 yield_now 上汇合，这很少见，值得留意。

“试图拆分一个计算密集型任务，可能会让它显著变慢，所以有时让某个操作短暂地阻塞，对整体性能反而更好”

“trying to break up a compute-bound task might make it significantly slower, so sometimes it’s better for overall performance to let an operation block briefly”

用三段代码教会你让出之后，它又告诉你别过头。拒绝把异步当作万能的好东西，很清爽。

“trpl::select 的实现并不公平：它总是按参数传入的顺序来轮询”

“The implementation of trpl::select is not fair: it always polls arguments in the order in which they are passed”

一个很好的承认：这个“原语”是有偏向的。timeout 之所以管用，只是因为参数顺序这个实现细节——可移植的代码不应该依赖它。

“因为流就是 future，我们可以把它们和任何其他种类的 future 一起使用”

“Because streams are futures, we can use them with any other kind of future”

有点草率——流并不是 future，它只是像 future 那样被轮询。这里的含糊，恰恰是后面 Stream trait 那一节要来澄清的。

“我们可以对 list 字段使用 HashSet<i32> 而不是 Vec<i32>”

“we could use a HashSet<i32> instead of a Vec<i32> for the list field”

说得轻描淡写，但 HashSet 会悄悄丢掉重复项，改变“平均”的含义。签名保住了；语义没有。

“不借助宏的话，没有办法定义一个继承父结构体的字段和方法实现的结构体。”

“There is no way to define a struct that inherits the parent struct’s fields and method implementations without using a macro.”

本章在这里不再含糊其辞，直接说了不。在一连串“按某些定义”之后，让人耳目一新。

“继承往往有共享了比必要更多的代码的风险。”

“Inheritance is often at risk of sharing more code than necessary.”

终于说出了真正的论点：继承把你想复用的东西和你不想复用的东西耦合在了一起。此前的一切都是分类学；这是一个设计上的论断。

“trait 对象与其他语言里的对象不同，我们不能往 trait 对象里添加数据。”

“Trait objects differ from objects in other languages in that we can’t add data to a trait object.”

本章中段的老实自白。trait 对象是半个对象——有行为而没有状态——作者直说了出来，而不是去兜售它。

“如果你只会有同质的集合，用泛型和 trait 约束更可取”

“If you’ll only ever have homogeneous collections, using generics and trait bounds is preferable”

注意真正的判断规则根本不是哲学性的：你在编译期知道这些类型吗？关于“面向对象对 Rust”的一切都坍缩成这一个问题。

“类似于动态类型语言里的鸭子类型概念”

“similar to the concept of duck typing in dynamically typed languages”

好类比，只是稍微太宽厚了。鸭子类型让你在运行时加一声新的嘎嘎叫；dyn Draw 需要在编译期就有那个 impl。共有的是对具体类型的漠不关心，而不是共有的自由。

“help: the trait `Draw` is implemented for `Button”

编译器主动递上了一个就在手边的正确答案。错误信息即教学——而本章懂得直接展示它，而不是去解释它。

“用户不会在状态上出错，比如在审核之前就发布一篇文章”

“users can’t make a mistake with the states, such as publishing a post before it’s reviewed”

值得抓住的一个强论断。在这第一版里，对草稿调用 approve() 不会报错——它悄悄地什么都不做。这不是在防止错误，而是在吞掉错误。

“因为 Post 的 state 字段是私有的，所以没有办法创建出处于其他任何状态的 Post！”

“Because the state field of Post is private, there is no way to create a Post in any other state!”

私有性在干不变量的活。那个感叹号，是书在悄悄承认：这是这个模式能买到的唯一保证。

“我们把 content 字段设成一个新的空 String”

“we set the content field to a new, empty String”

值得注意，content 住在 Post 上，而不是状态上——这正是两页之后将要裂开的那条缝。

“这种语法意味着，只有在持有该类型的 Box 上调用，这个方法才有效。”

“This syntax means the method is only valid when called on a Box holding the type.”

self: Box<Self> 是整章的枢纽：所有权转移是 Rust 拼写“旧状态已不复存在”的方式。面向对象语言只是改一个指针然后祈祷。

“因为 Rust 不允许结构体里有未填充的字段”

“because Rust doesn’t let us have unpopulated fields in structs”

著名的 Option::take 舞步。Option 根本不是在建模“缺席”——它是为了满足借用检查器而设的一个暂存槽。这是模式带来的建模噪音，而不是领域本身的。

“虽然方便，但让 State 上的 content 方法来决定 Post 的内容，是在模糊界线”

“While convenient, having the content method on State determine the content of the Post is blurring the lines”

书在句子进行到一半时就嗅到了自己的这股味道。State 现在伸手进了 Post 的字段——它承诺的封装，在往相反的方向泄漏。

“我们知道它永远不会 panic，因为我们知道 Post 上的方法确保”

“we know will never panic because we know the methods on Post ensure”

一个从句里有两个“我们知道”。现实中每一个 unwrap 都是这句话，而这句话有时是错的。

“我们就得改动 PendingReview 里的代码，让它转换到 Scheduled 而不是 Published”

“we would have to change the code in PendingReview to transition to Scheduled instead”

真正的控诉：加一个状态，要去改一个已有的状态。这个模式把行为局部化了，却把状态图的接线散布到了它自己的各个节点上。

“trait 并不确切知道具体的 self 是什么，所以返回类型在编译期是未知的”

“the trait doesn’t know what the concrete self will be exactly, so the return type isn’t known at compile time”

动态分派和所有权转移朝相反的方向拉扯——你不可能既有一个 dyn trait，又有一个返回 Self 的默认实现。重复不是马虎，而是一种结构性的税。

“我们会让草稿文章根本没有 content 方法”

“we’ll make it so that draft posts don’t have the content method at all”

倒转：别再给出错误的回答，让问题没法被问出口。这就是 Rust 的整套招数，一行说完，也是以面向对象为代价的一个类型层面的玩笑。

“编译器不检查穷尽性，而 match 表达式则会检查”

“the compiler doesn’t check for exhaustiveness, whereas with match expressions it does”

if let 的老实价码。你用简洁换来的，是一次沉默——原来编译器会冲你大喊的地方。

“一旦发送端断开，就会产生一个 Err”

“produces an Err once the sender side disconnects”

优雅：循环的终止条件不是计数器，而是发送者的消亡。通道一端的生命周期成了控制流。

“编译器会警告不可反驳的模式，因为按定义，它们是为处理可能的失败而设的”

“the compiler warns against irrefutable patterns because, by definition, they’re intended to handle possible failure”

Rust 管的不只是正确性，还有意图——写一个不可能失败的条件语句，是在表明你自己的困惑，而它如实说了出来。

“这是一个新的 y 变量，不是我们在开头声明的那个值为 10 的 y”

“this is a new y variable, not the y we declared at the beginning with the value 10”

本章是先把它摆成一道谜题，再去解释的——很好。match 分支里的遮蔽，是人们最常读错自己代码的唯一一处。

“Rust 能判断范围是否为空的类型，只有 char 和数值”

“the only types for which Rust can tell if a range is empty or not are char and numeric values”

一个被表述为后果而不是规则的限制。这个限制不是随意的口味；它是编译器真正能验证的东西的边界。

“尽管 Point { x: 0, y: 0 } 既在 x 轴上也在 y 轴上，这段代码在 0 处只会打印 On the x axis”

“even though Point { x: 0, y: 0 } is on the x axis and the y axis, this code would only print On the x axis at 0”

分支的顺序是语义，不是风格。模式看上去是声明式的，但它们是自上而下解析的——重叠要由你来管理。

“当你需要某个类型签名，但你实现里的函数体不需要其中某个参数时，你正在实现一个 trait”

“you’re implementing a trait when you need a certain type signature but the function body in your implementation doesn’t need one of the parameters”

签名里用 _ 的真正理由：形状是由外部决定的。Rust 的警告是关于意图的一场对话，而 _ 就是你说“对，我是故意的”的方式。

“不应该允许用户覆盖某项设置已有的自定义值”

“the user should not be allowed to overwrite an existing customization of a setting”

漂亮的障眼法——一条业务规则被伪装成语法演示。Some(_) 这种匹配的存在，恰恰是为了“我在乎它在不在，不在乎它是什么”。

“_x 这种语法仍然会把值绑定到变量上，而 _ 根本不绑定。”

“The syntax _x still binds the value to the variable, whereas _ doesn’t bind at all.”

这是整节里唯一真正会咬人的一行。_x 看上去像个弱化的 _，其实是一次乔装打扮的完整绑定——而所有权不读命名约定。

“当涉及 match 守卫表达式时，编译器不会尝试检查穷尽性”

“the compiler doesn’t try to check for exhaustiveness when match guard expressions are involved”

代价说得很直白，然后就放下了。你换来了任意的表达能力，付出的是穷尽性保证——而那正是 Rust 对 match 的全部卖点。

“match 守卫 if n == y 不是模式，因此不会引入新变量。”

“The match guard if n == y is not a pattern and therefore doesn’t introduce new variables.”

这个解法是概念性的，不是机巧的：把比较从模式语言里挪到普通表达式的领地。模式绑定；条件读取。一旦你看到这一行，示例 19-11 的陷阱就不再神秘了。

“4 | 5 | 6 if y => println!("yes"),”

优先级的问题，只有靠有人把带括号的版本写下来才能定案。书老实承认它“看上去可能像”另一种读法——这恰恰是你会交付出去的那个 bug。

“变量名 second 对 Rust 来说没有任何特殊含义”

“The variable name second doesn’t mean anything special to Rust”

对那位以为给东西起个名就让它有意义的读者的一点温和的讽刺。编译器拒绝这个模式，不是因为它错了，而是因为它没有唯一的答案——是歧义，不是错误。

“使用 @ 让我们可以在一个模式里测试一个值，并把它保存到变量中。”

“Using @ lets us test a value and save it in a variable within one pattern.”

前面两段是靠展示没有 @ 你会失去什么来解释它的——一个知道自己匹配上了、却不知道匹配上了什么的范围分支。在这里，用缺席来教，比下定义更管用。

“让 unsafe 块保持小；以后你调查内存 bug 时会感谢自己的。”

“Keep unsafe blocks small; you’ll be thankful later when you investigate memory bugs.”

这个关键字真正的理由不是预防，而是可以 grep。unsafe 是一件伪装成权限系统的调试辅助。

“借用切片的不同部分从根本上说是可以的，因为这两个切片并不重叠，但 Rust 没有聪明到能知道这一点。”

“Borrowing different parts of a slice is fundamentally okay because the two slices aren’t overlapping, but Rust isn’t smart enough to know this.”

split_at_mut 是完美的教学案例：程序员的证明微不足道（mid ≤ len），编译器的证明则不可能。安全最终落在一个由人检查过的断言上。

“把一个函数标记为安全，并不本质上让它安全！”

“Marking a function as safe does not inherently make it safe!”

safe 是一种承诺，而不是一种属性——和 unsafe 是同一个把戏，只是反过来。这里 Rust 的关键字是言语行为，而不是验证。

“每当我们写一个 unsafe 函数时，惯例是写一条以 SAFETY 开头的注释”

“Whenever we write an unsafe function, it is idiomatic to write a comment starting with SAFETY”

令人吃惊的是，契约住在一条注释里。在类型系统所能表达的边界上，Rust 退回到了散文——只靠文化来强制。

“借用检查器是一个在编译期工作的静态工具，而 Miri 是一个在运行时工作的动态工具。”

“Whereas the borrow checker is a static tool that works at compile time, Miri is a dynamic tool that works at runtime.”

一旦你走出编译器的证明，你就回到了测试——恰恰是 Rust 自称已经超越的那种体制。Miri 悄悄地恢复了旧的交易。

“如果 Miri 确实抓到了问题，你就知道有 bug，但 Miri 没抓到 bug，并不意味着没有问题”

“If Miri does catch a problem, you know there’s a bug, but just because Miri doesn’t catch a bug doesn’t mean there isn’t a problem”

诚实的不对称，说得很直白：这个工具大致可靠，但从不完备。教程很少承认自己的安全网有洞。

“关联类型处在中间：它们比书中其余部分讲的特性用得少，但比本章讨论的许多其他特性更常用”

“Associated types are somewhere in the middle: They’re used more rarely than features explained in the rest of the book but more commonly than many of the other features discussed in this chapter”

书不断按使用频率给自己的内容打分。一个安静的教学承诺：你可以略读，但这里别略读。

“有了关联类型，我们不需要标注类型，因为我们不能对一个类型多次实现同一个 trait”

“With associated types, we don’t need to annotate types, because we can’t implement a trait on a type multiple times”

整堂课就在一个分句里：限制就是好用。放弃通用性，在每一个调用点换来了沉默。

“为了在不破坏现有代码的前提下扩展一个类型”

“To extend a type without breaking existing code”

默认类型参数其实是伪装成类型工具的版本管理工具——向后兼容被偷渡进了类型系统。

“Millimeters(self.0 + (other.0 * 1000))”

有意思的是，自定义 Rhs 的经典例子是单位换算——newtype 模式悄悄地防止了一类“火星轨道器”式的 bug。

“因为 Animal::baby_name 没有 self 参数，而且可能有其他类型实现了 Animal trait，Rust 无法弄清楚该用哪个实现”

“Because Animal::baby_name doesn’t have a self parameter, and there could be other types that implement the Animal trait, Rust can’t figure out which implementation”

没有 self 就是整个故事。方法分派不是魔法，只不过是多一份证据——把它拿掉，编译器就两眼一抹黑。

“这种技巧类似于给 trait 添加一个 trait 约束”

“This technique is similar to adding a trait bound to the trait”

父 trait 去神秘化：不是继承，只是处在不同位置的一个约束。值得抵制“super”这个词所邀请的面向对象读法。

“使用这种技巧的缺点是，Wrapper 是一个新类型，所以它没有它所持有的那个值的方法”

“The downside of using this technique is that Wrapper is a new type, so it doesn’t have the methods of the value it’s holding”

绕开孤儿规则的办法收取了样板代码的过路费。然后又拿 Deref 当作逃生口——而它本身恰恰是 Rust 在别处警告不要滥用的做法。

“newtype 模式是实现封装、隐藏实现细节的一种轻量方式”

“The newtype pattern is a lightweight way to achieve encapsulation to hide implementation details”

一个零成本的包装器，干着别处私有字段和模块干的事——别的语言伸手去拿访问关键字的地方，Rust 一再伸手去拿类型系统。

“如果我们在某个地方把 Kilometers 和 i32 的值混在一起，编译器不会给我们报错”

“if we mix up Kilometers and i32 values somewhere, the compiler will not give us an error”

老实的承认：别名买来了可读性，在安全上什么也没换回来。给一个东西起名，不等于让它成为一个东西。

“thunk 是指稍后才会被求值的代码的一个说法”

“thunk is a word for code to be evaluated at a later time”

一个安静的论点：命名是设计工作，不是装饰——别名告诉读者这个类型是拿来干什么的，而完整的写法从来没做到这一点。

“可是，一个你永远没法创建值的类型，有什么用？”

“But what use is a type you can never create values for?”

好招——在读者嘟囔出声之前，先把他们的怀疑大声问出来。答案很可爱：! 恰恰因为它是空的才有用，所以它能强制转换到任何地方而不撒谎。