即使關聯類型不同，特征實現也有沖突

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 集成，這將使它更容易實現。

同時，您必須使用上面提出的解決方法。