为什么迭代器的实现<item = t>和迭代器<item = &t>矛盾的？</item></item>

Question

此代码无法编译：

pub trait ToVec<T> {
    fn to_vec(self) -> Vec<T>;
}

impl<I, T> ToVec<T> for I
where
    I: Iterator<Item = T>,
{
    fn to_vec(self) -> Vec<T> {
        self.collect()
    }
}

impl<'a, I, T> ToVec<T> for I
where
    I: Iterator<Item = &'a T>,
    T: Clone,
{
    fn to_vec(self) -> Vec<T> {
        self.cloned().collect()
    }
}

错误：

error[E0119]: conflicting implementations of trait `ToVec<_>`:
  --> src/lib.rs:14:1
   |
5  | / impl<I, T> ToVec<T> for I
6  | | where
7  | |     I: Iterator<Item = T>,
8  | | {
...  |
11 | |     }
12 | | }
   | |_- first implementation here
13 | 
14 | / impl<'a, I, T> ToVec<T> for I
15 | | where
16 | |     I: Iterator<Item = &'a T>,
17 | |     T: Clone,
...  |
21 | |     }
22 | | }
   | |_^ conflicting implementation

据我了解，当给定类型I实现Iterator时， I::Item只能具有一种特定类型，因此它不能同时满足两种实现。

这是编译器的限制还是我的推理不正确？ 如果是这样，请提供一个同时满足这两个 impls 的示例。

Answer 1

我相信这是问题 #20400， Can't write non-overlapping Blank impls that involved associated type bindings 。 总而言之， impl实际上是不重叠的，但是教编译器认识到这会引入一种否定推理形式，这与 trait solver 当前的工作方式有很大不同。 编写了一个 RFC来解决这个问题，但部分原因是由于对两种类型重叠的含义不明确，所以推迟了。

这个问题似乎最终会被重新审视和修复，但可能需要一些时间。

同时，您可能会编写一个基于向Trait添加类型参数的解决方法，如我对Can I Avoid eager ambiguity resolution for trait implementations with generics? （尽管在您的情况下，由于您的impl s实际上从不重叠，因此您不必使用 turbofish 来选择impl ；编译器应该始终弄清楚。）

Answer 2

粗略地说，带有Item = &X的迭代器将同时满足：

• 第一个T == &X => 可能导致Vec<&X>
• 带有T == X => 的第二个可能导致Vec<X>

也许专业化（每晚）会有所帮助，但我不确定。

Answer 3

泛型类型参数T表示的类型集是泛型类型参数&T表示的类型集的超集。 它们并不脱节。 &T中的所有内容也在T中，因此存在冲突的实现消息。

最小的例子：

trait Trait {}

impl<T> Trait for T {}

impl<T> Trait for &T {} // compile error

抛出：

error[E0119]: conflicting implementations of trait `Trait` for type `&_`:
 --> src/lib.rs:5:1
  |
3 | impl<T> Trait for T {}
  | ------------------- first implementation here
4 | 
5 | impl<T> Trait for &T {} // compile error
  | ^^^^^^^^^^^^^^^^^^^^ conflicting implementation for `&_`