arrays - 尽可能使用 `Iterator` 而不是 `Vec`？

Question

当函数接受一系列值作为参数时，接受 Iterator<T> 是否被认为是好的风格？而不是 Vec<T> ？

这样，调用者可以自行决定系列的存储方式(在 Vec、[T; N] 或其他任何东西中，实际上 Option<T> 应该是可能的!)。此外，这消除了将您拥有的任何东西转换为 Vec 的需要。 ，并且在应用一些 Iterator 修饰符之后，没有 .collect()需要!所以它也应该更快!

我是不是遗漏了什么或者这是应该的方式吗？

Answer 1

您描述的此类函数通常通常采用 IntoIterator<Item = T> ;因此它可以同时接受 Iterator<T>和 Vec<T>作为输入。

这也可以与其他技术结合使用；例如，此方法 concat将接受 &[&str] (因此 &Vec<&str> 通过自动取消引用/引用强制)，&[String] (因此 &Vec<String> )，一个 &str迭代器，一个 String迭代器，等等:

use std::borrow::Borrow;

fn concat<T: Borrow<str>, Iter: IntoIterator<Item = T>>(iter: Iter) -> String {
    iter.into_iter()  // -> impl Iterator<Item = T>
        .map(|s| s.borrow()) // -> impl Iterator<Item = &str>
        .collect()  // -> String
}

(这个具体示例实际上通常更适合 SliceConcatExt ，因为它能够预先计算出最终结果的长度，从而一次性分配正确长度的字符串。但这只是证明概念以及如何组合多种奇特的技术。)