即使关联类型不同，特征实现也有冲突

Question

我正在尝试创建一个通用结构，它包装isize或AtomicIsize ，但是当我尝试为结构的两种可能实现实现特征时遇到错误。 我创建了一个最小示例，它在下面演示了我的问题。

use std::sync::atomic::{AtomicIsize, Ordering};
use std::ops::Deref;
use std::marker::PhantomData;

pub trait Counted {
    fn inc(&self, value: isize);
}

pub type PlainCounter = isize;
pub type AtomicCounter = AtomicIsize;


pub struct Counter<'a, T: 'a> {
    counter: T,
    phantom: PhantomData<&'a T>,
}

impl<'a, T> Counter<'a, T>
    where T: Deref<Target = PlainCounter>
{
    pub fn new(counter: T) -> Self {
        Counter {
            counter: counter,
            phantom: PhantomData,
        }
    }
}

impl<'a, T> Counted for Counter<'a, T>
    where T: Deref<Target = PlainCounter>
{
    fn inc(&self, value: isize) {
        self.counter += 1;
    }
}

impl<'a, T> Counter<'a, T>
    where T: Deref<Target = AtomicCounter>
{
    pub fn new(counter: T) -> Self {
        Counter {
            counter: counter,
            phantom: PhantomData,
        }
    }
}

impl<'a, T> Counted for Counter<'a, T>
    where T: Deref<Target = AtomicCounter>
{
    fn inc(&self, value: isize) {
        self.counter.fetch_add(value, Ordering::SeqCst);
    }
}

（ 操场）

我得到的错误是编译器发现conflicting implementations of trait `Counted` for type `Counter<'_, _>` 。 似乎编译器无法确定实现是针对两种不同类型的T ，即T: Deref<Target = PlainCounter>和T: Deref<Target = AtomicCounter> 。 有没有办法向编译器提供附加信息，以便它可以区分这两种情况，还是我完全走错了路？

Answer 1

您可以通过定义执行实际工作的第二个特征来完成此模式，并为(Counter<'a, T>, <T as Deref>::Target) ，并让Counter特征调用该实现。

我认为这不是很清楚，但我认为一个例子可以很好地说明。 为清楚起见，使用 Shepmaster 较短的示例，我们将从以下内容出发：

use std::ops::Deref;

trait Foo {}

impl<T> Foo for T
    where T: Deref<Target = u8>
{}

impl<T> Foo for T
    where T: Deref<Target = bool>
{}

fn main() {}

对此：

use std::ops::Deref;

trait Foo {}
trait InnerFoo {}

impl<T> Foo for T
    where T: Deref,
          (T, <T as Deref>::Target): InnerFoo
{}

impl<T> InnerFoo for (T, u8)
{}

impl<T> InnerFoo for (T, bool)
{}

fn main() {}

Answer 2

不幸的是，这还没有在语言中实现。

有这个跟踪问题： rust-lang/rust#20400 。

一个 RFC rust-lang/rfcs#1672也被提出来解决这个问题，但后来被推迟，等待Chalk 集成，这将使它更容易实现。

同时，您必须使用上面提出的解决方法。