什么时候只需要 PartialEq 而不是 Eq 合适? [英] When is it appropriate to require only PartialEq and not Eq?

问题描述

我正在阅读 Rust 书并尝试了解 PartialEq 和 Eq 特征的用例.

I am reading the Rust book and trying to understand use cases for PartialEq and Eq traits.

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

I realise that PartialEq is for relations which are not necessarily reflexive (i.e. there can be such x that x != x) and that Eq is a marker trait which says that relation is also reflexive (and now it is a proper equivalence relation).

书中给出了一个例子，其中 PartialEq 是不够的，而 Eq 是必需的:HashMap 查找.事实上，如果我们使用只实现 PartialEq(例如浮点数)的数据类型作为键，当我们尝试使用 NaN 作为关键，因为我们将无法找到它.

The books gives an example where PartialEq is not enough and Eq is required: HashMap<K, V> lookups. Indeed, if we use as a key a data type which only implements PartialEq (for example floating point number), we would get in trouble when we try to use NaN as a key, since we won't be able to find it.

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

Now, I am trying to understand what feature of a lookup makes it require Eq. I may be able to understand it better if I find an example of code which does not require Eq.

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

The book says that assert_eq! requires only PartialEq so that we are able to compare things for equality. But if we write assert_eq!(f64::NAN, some_code_producing_nan()); in a test, the test will always fail. We have the same basic issue as with using a PartialEq key in a HashMap, but for some reason it is considered appropriate here.

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

What is an example of a reasonable function which requires only PartialEq and adding Eq is not desirable/does not make sense?

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

If there are no such use cases, then why do we care about splitting it into two traits PartialEq / Eq? Haskell, for example, just has Eq.

推荐答案

决定何时使用 PartialEq vs Eq 应该根据使用是否需要 x == x.

Deciding when to use PartialEq vs Eq should be based on whether the use requires that x == x.

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

The question is not about whether it is possible to compare x to x but rather if that comparison happens, does the use depend on x==x always holding? If the answer is yes, use Eq. Otherwise prefer the weaker constraint PartialEq.

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

assert_eq!doesn't depend on x==x always holding so there is no need to force that constraint on the caller. As OP succinctly mentioned 2 examples in the comments:

如果我们执行 assert_eq!(NAN, products_nan()) - 我们的问题是它给出了 false，但是如果我们查找 NAN 键在 HashMap 中，这将是 HashMap 的问题，因为它违反了它的查找契约(它应该能够找到所有的键放入地图)

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)

这篇关于什么时候只需要 PartialEq 而不是 Eq 合适?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！