为什么 Iterator<Item = T> 和 Iterator<Item = &T> 的实现会发生冲突？

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 blanket impls that involve associated type bindings。总而言之，impls 实际上是不重叠的，但教编译器认识到这会引入一种否定推理形式，这与 trait solver 目前的工作方式有很大不同。 An RFC 是为了解决这个问题而编写的，但部分原因是由于两种类型重叠的含义不明确而被推迟。

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

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

Answer 2

泛型类型参数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 `&_`

Answer 3

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

• 第一个带有T == &X => 的结果可能是Vec<&X>
• 第二个带有T == X => 的结果可能是Vec<X>

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