rust - 为什么对 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

To fix the bug, I converted them to:

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

视平台而定， usize可以是 64b， isize尽管它仍然只有 usize 的正值范围的一半，但它的存在是为了区分用途。 , 转换到 i128将提供更多的确定性(至少在我们获得具有 128b 使用率的平台之前)但随后它可能非常低效，例如32b 平台，因为它们可能没有对 128b 操作的硬件支持，而是在软件中实现。

Why Rust doesn't convert usize substraction to a signed type?

因为数字类型的算术运算是使用宏通过相同的输入和输出批量实现的。
您建议的选项只会有其自身的问题，例如 usize::MAX - 1会退回垃圾。

What's Rust idiomatic way to catching this type of bugs early during compile time?

数字类型具有显式溢出行为的方法:失败( checked_* )、包装( wrapping_* )或饱和( saturating_* )。有一种包装操作的包装类型，因为这在某些上下文(例如密码学)中很常见，但我认为没有用于检查操作的包装类型。
没有真正惯用的方法来处理这个问题，因为这是一个个案的问题，并且有一次这种失败被判断为太不方便和不习惯，默认情况下无法浮出水面。