在的文档Ord中，它说
实现必须与 PartialOrd 实现一致 [...]
这当然是有道理的，并且可以轻松存档，如下面的示例所示：
impl PartialOrd for MyType {
fn partial_cmp(&self, other: &Self) -> Option<Ordering> {
Some(self.cmp(other))
}
}
我想知道，为什么他们会把这种负担/风险留给我们用户而不是有一条毯子impl<T: Ord> PartialOrd for T { /* ... */ }。
我测试了循环依赖问题和游乐场中的东西，但这正如我所期望的那样。互联网也没有产生任何结果。
我能想到的另一个原因是derive宏现在的工作方式。人们可能必须将每个替换derive(PartialOrd, Ord)为 just derive(Ord)（或者使宏变得PartialOrd更智能 - 我不知道它是否可以变得那么智能）。
添加建议的总体实现将禁止自定义实现PartialOrd并消除一致性要求。当然，这对图书馆来说是一个重大改变。这是唯一的原因，还是我在这里遗漏了一些其他论点？
我看源代码的cat从GNU的coreutils，特别是圆检测。他们正在比较设备和 inode 并且工作正常，但是有一种额外的情况，如果输入为空，他们允许输出为输入。查看代码，这必须是lseek (input_desc, 0, SEEK_CUR) < stat_buf.st_size)部分。我阅读了从 中找到的联机帮助页和讨论git blame，但我仍然不太明白为什么lseek需要调用。
这是如何cat检测的要点，如果它会无限耗尽磁盘（请注意，为了简洁起见，还删除了一些错误检查，完整的源代码在上面链接）：
struct stat stat_buf;
fstat(STDOUT_FILENO, &stat_buf);
out_dev = stat_buf.st_dev;
out_ino = stat_buf.st_ino;
out_isreg = S_ISREG (stat_buf.st_mode) != 0;
// ...
// for <infile> in inputs {
input_desc = open (infile, file_open_mode); // or STDIN_FILENO
fstat(input_desc, &stat_buf);
/* Don't copy a nonempty regular file to itself, as that would
merely exhaust the output device. It's …我说的是std::collections::hash_map::Values结构体，它是.values()通过在HashMap. 这个结构真的让我感到困惑，如何在不迭代它们的情况下访问它的值？我想把这些值变成BinaryHeap这样：
let heap = BinaryHeap::from(map.values());
我阅读了文档，似乎这个结构并没有真正访问其元素的简单方法