为何Rust中BTreeMap的Iter迭代器未实现count方法？

我对Rust中BTreeMap的Iter迭代器的Iterator实现有疑问：它仅重写了部分Iterator trait方法，但明明可以直接返回length字段来实现count方法，却使用了默认的遍历next的方式，想搞清楚这里的设计细节。

对应的Iter实现代码如下：

#[stable(feature = "rust1", since = "1.0.0")]
impl<'a, K: 'a, V: 'a> Iterator for Iter<'a, K, V> {
    type Item = (&'a K, &'a V);

    fn next(&mut self) -> Option<(&'a K, &'a V)> {
        if self.length == 0 {
            None
        } else {
            self.length -= 1;
            Some(unsafe { self.range.next_unchecked() })
        }
    }

    fn size_hint(&self) -> (usize, Option<usize>) {
        (self.length, Some(self.length))
    }

    fn last(mut self) -> Option<(&'a K, &'a V)> {
        self.next_back()
    }

    fn min(mut self) -> Option<(&'a K, &'a V)>
    where
        (&'a K, &'a V): Ord,
    {
        self.next()
    }

    fn max(mut self) -> Option<(&'a K, &'a V)>
    where
        (&'a K, &'a V): Ord,
    {
        self.next_back()
    }
}

核心原因：默认count方法已通过size_hint实现优化 #

其实不需要显式实现count，因为标准库的Iterator默认count方法已经会利用size_hint的精确值做优化：

• 这个Iter实现已经重写了size_hint，返回(self.length, Some(self.length))，明确告知迭代器剩余元素的数量是精确的self.length。
• Rust标准库中Iterator::count的默认实现会检查size_hint的上下界是否一致，如果一致，就直接返回该数值，完全不会调用next遍历元素。

设计层面的考量 #

1. 减少代码冗余：实现size_hint比单独实现count更高效——size_hint能为多个Iterator方法提供优化基础，比如collect可以用它预先分配内存，nth能更高效定位元素，而不是只服务于count一个方法。
2. 保证行为一致性：依赖size_hint的统一优化逻辑，能确保所有相关方法的行为保持一致，避免重复实现可能带来的错误。

内容的提问来源于stack exchange，提问作者kmdr