Question

用于选择运营商! / && / ||而非not / and / or的理由是什么？它背后是否有一些历史，还是仅仅是偏爱？

我有一些想法：

严格遵循C / C ++ 。但是，在for-each循环的情况下，使用的是更for x in X的英语版本，而不是C ++的for (x: X)，因此Rust并没有盲目地遵循C / C ++。
符号较短。两者之间的字符数似乎相似。
由于与类型规范的冲突，语法必须有所不同。 a as u8而非(u8)a也有所不同。

由于Rust是一种新语言，所以我认为他们可以选择符号或单词而不会出现问题。 Rust选择单词而不是符号的原因是什么？为什么不选择两者？

Answer 1

早在2006年，Graydon Hoare就开始将Rust作为一个小项目进行研究。 Hoare还研究了Servo浏览器引擎。他对Rust的目标是，它可能有助于开发所说的浏览器引擎。由于该引擎（几乎与所有其他浏览器引擎一样）当时都是用C ++编写的，因此Rust基本上是Hoare的C ++替代品。

因此使用与C ++相同的逻辑运算符似乎很自然。

2010年创建GitHub存储库时，&&和||已经使用Rust语言。参见the lazy-and-or.rs test during the second commit in the repository：

if (true && x) { ... }

随着时间的流逝，语言设计过程变得更加民主，并且出现了更多的想法。但是直到2016年someone officially proposed adding not, and and or as an RFC。

但是您可以看到RFC已关闭。没有船的贡献者是这样解释的：

如果我从一开始就设计一种语言，我可能会更喜欢and和or。但是，除非绝对必要，否则我们通常会反对上下文关键字，除非在表达上下文中特别难以引入上下文关键字，而且我们倾向于避免使用“摘自毒药”的语法糖。

重要的是，此时!，&&和||已经稳定了一年多。因此，唯一的选择是添加替代运算符，而不是替换那些。这似乎不值得。

^{免责声明：我仅在2014年加入Rust社区。在IRC或其他我无法搜索的媒体中，可能对此进行了更大的讨论。但这就是我能找到的全部。}