rust - 什么时候只需要 PartialEq 而不需要 Eq 是合适的？

Question

我正在阅读 the Rust book并尝试了解 PartialEq 的用例和 Eq特质。

我意识到 PartialEq用于不一定自反的关系(即可以有这样的 x 那个 x != x )和那个 Eq是一个标记特征，表示该关系也是自反的(现在它是一个适当的等价关系)。

书中给出了一个例子，其中PartialEq还不够 Eq必填项:HashMap<K, V>查找。实际上，如果我们使用仅实现 PartialEq 的数据类型作为键(例如 float )，当我们尝试使用 NaN 时会遇到麻烦作为 key ，因为我们将无法找到它。

现在，我试图了解查找的什么特性使其需要 Eq .如果我找到一个不需要 Eq 的代码示例，我可能会更好地理解它.

书上说assert_eq!只需要 PartialEq这样我们就可以比较事物的平等性。但是如果我们写 assert_eq!(f64::NAN, some_code_producing_nan());在测试中，测试总是会失败。我们遇到与使用 PartialEq 相同的基本问题键入 HashMap , 但出于某种原因，它在这里被认为是合适的。

什么是只需要 PartialEq 的合理函数的示例？并添加 Eq是不可取的/没有意义？

如果没有这样的用例，那我们为什么要关心将它分成两个特征 PartialEq/Eq ？例如，Haskell 只有 Eq .

Answer 1

决定何时使用 PartialEq 与 Eq 应该基于使用是否需要 x == x。

问题不在于是否可以将 x 与 x 进行比较，而是如果发生这种比较，使用是否取决于 x==x 一直持有？如果答案是肯定的，请使用 Eq。否则更喜欢较弱的约束 PartialEq。

assert_eq!不依赖于 x==x 始终保持不变，因此无需对调用者施加该约束。正如 OP 在评论中简洁地提到的 2 个示例:

if we do assert_eq!(NAN, produces_nan()) - it's our problem that it gives false, but if we do a lookup of a NAN key in a HashMap, it would be a problem of the HashMap, because it would violate its lookup contract (that it should be able to find all the keys put in the map)