为什么Iterator :: next返回一个Option而不仅仅是一个项目？

Question

在我看来，一个选项是否是正确的返回类型应由实现者决定。

我注意到当我尝试在项目上过滤或使用其他收集方法时它会消失。这只是has_next的替代品吗？不会有潜在的性能/内存影响吗？

Answer 1

因为需要一些方式与来电者沟通，所以没有什么可以输出。

fn main() {
    let mut it = vec![1, 2, 3].into_iter();
    assert_eq!(it.next(), Some(1));
    assert_eq!(it.next(), Some(2));
    assert_eq!(it.next(), Some(3));
    assert_eq!(it.next(), None); // End of iterator.
}

对于假设的has_next，这会使一些迭代器设计复杂化，因为它需要迭代器来知道是否还有其他元素。这可能需要迭代器来计算下一个元素，然后将其存储在某个地方。也可以忘记拨打has_next，或者拨打电话但忽略结果。

next返回Option，这都不是问题;迭代器可以计算下一个项目并返回它，同时使调用者无法忘记确保返回的值实际上有内容。

不让你做的一件事是＆＃34;偷看＆＃34;在迭代器中查看是否有更多内容然后根据该答案更改逻辑，没有实际消耗下一个项目。但是，这就是peekable组合器的用途，它可以为您提供传统的has_next：peek().is_some()。

关于你对表现的担忧：我从来没有看到任何暗示有任何惩罚的事情。正确使用迭代器的任何东西都有来检查它是否到达终点。至于空间，Rust迭代器不需要缓存下一个项目，因此它们可能与使用has_next的语言的迭代器相同或更小。

最后，如评论中所述，Option未分配堆。 None相当于false后跟一些未初始化的空格（因为其中没有任何内容），而Some(v)相当于true后跟v。