为什么 usize 数字的减法运算不能为负数，Rust 处理这个问题的惯用方法是什么？

Question

s和t是向量。如果我们这样做：

t.len() - s.len()

attempt to subtract with overflow如果减法结果为负，则可能会导致错误（因为两种类型都是usize）。

然而，如果我们不知道这两种类型都是，usize并且我们期望结果可能是负数，则可能会导致一个棘手的错误（我自己也遇到过，并且只在运行时的边缘情况下捕获它）。为了修复该错误，我将它们转换为：

t.len() as i32 - s.len() as i32

我的问题是：

• 为什么 Rust 不将usize减法转换为有符号类型？
• 在编译时尽早捕获此类错误的 Rust 惯用方法是什么？

Answer 1

为了修复该错误，我将它们转换为：

t.len() as i32 - s.len() as i32

根据平台的不同，usize可以是 64b，isize存在的目的是比较 usize，尽管它仍然只有 a 的正范围的一半usize，转换为i128将提供更多的确定性（至少在我们获得具有 128b usize 的平台之前），但随后它可能会非常在例如 32b 平台上效率较低，因为它们可能没有对 128b 操作的硬件支持，而是以软件实现。

为什么 Rust 不将 usize 减法转换为有符号类型？

因为数字类型的算术运算是使用宏使用相同的输入和输出批量实现的。

您建议的选项只会有其自身的问题，例如usize::MAX - 1会返回垃圾。

在编译时尽早捕获此类错误的 Rust 惯用方法是什么？

数字类型具有显式溢出行为的方法：失败 ( checked_*)、包装 ( wrapping_*) 或饱和 ( saturating_*)。有一种用于包装操作的包装类型，因为这在某些上下文（例如密码学）中非常常见，但我认为没有用于检查操作的包装类型。

没有真正惯用的方法来处理这个问题，因为这是一个具体问题具体分析的问题，并且这一次这种失败被认为太不方便并且不习惯默认情况下出现。