为什么 Rust 的整数设计更胜一筹？
Thoughts on Integers (2023)
我深入探讨了主流编程语言中整数类型的现状，从 C 的未定义行为到 C#、Go 和 Swift 的默认类型偏好。我发现大多数语言都倾向于使用有符号的 int，这往往导致开发者偷懒而忽略最佳类型选择。相比之下，Rust 通过强制显式指定大小和符号（如 i32、u64），消除了这种偏见，迫使开发者根据场景做出判断。文章还分析了为何 C 语言将整数溢出设为未定义行为，以及这如何影响编译器优化。作为一名 Rust 开发者，尝试在其他语言中使用无符号整数作为数组索引时，我因繁琐的类型转换而感到沮丧，这更坚定了我的观点：Rust 的整数类型设计才是更合理、更安全的选择。
如果你希望一个整数在算术运算中被处理，而不是在某个模空间（2 的幂次方）中，那就把它做成有符号的。
HN 评论区
11- mike_hock
> C 有一堆令人困惑的、依赖机器的类型，比如 ptrdiff_t 和 size_t
有什么好困惑的？它们本质上就是 int 和 unsigned int 本该有的样子。只是后来他们意识到自己搞出了一堆无法扩展的烂摊子，所以不得不加些新名字。
结果在搞这些的时候，他们又制造了下一批无法扩展的烂摊子，所以现在连 int128 都加不进去了。
- krick
我不明白结论到底是什么。按理说我应该“起初不同意，最后被说服”，但我最后连自己该同意还是反对什么、该被说服什么全搞糊涂了。
文章开头的前提是“C/C++ 的类型系统烂透了，看看 Rust 里的整数类型名多优雅”，还说如果我们试图建模 ℕ（自然数集），应该把无符号整数作为首选近似。我是不是该反对这些？作者似乎并没有在反驳它们，而且这些说法看起来都是显而易见、毫无争议的真理。
接着文章开始说我们在 C/C++ 中无法正确使用无符号整数，因为那东西烂透了，而且无法妥善修复，因为正确处理整数太昂贵了。这一切听起来都令人悲哀地耳熟，我们只能点头说：“唉，生活就是这样。”但至少我们还有 Rust，它不受同样的固有未定义行为（UB）诅咒，对吧？我的意思是，我对当前编译器实现的细节了解得不够深，但我得到的印象是，文中描述的那些问题并不适用于 Rust。那一切就都好了？（编辑：显然，除了我们仍然在生产构建中允许溢出，因为不这么做太昂贵了。但这大家早就知道了。）
随后文章又举了一些在我看来相当牵强的例子，说明我们不能盲目地把 int 换成 uint（这还用说吗？在这个例子里你基本上就是显式检查 `i == -1`），却把这包装成“……