Rust detects a conflict between non-conflicting implementations of a trait

[p-avital]

Hello,

When trying to do some type-fu in a much larger project, I stumbled on a conflict detection which shouldn't happen. Here's a minimal version of the issue:

struct A;
struct B;
trait Specializer {
    type Key;
}
trait Conflict {
    fn conflict(&self);
}
struct C<T>(T);
// A first implementation, note that `A` is a concrete type.
impl<T: Specializer<Key=A>> Conflict for C<T> {
    fn conflict(&self) {}
}
// A second implementation, note that `B` is also a concrete type.
// Since `T` can only impl `Specializer` once, no type can impl both `Specializer<Key=B>` and `Specializer<Key=A>`
impl<T: Specializer<Key=B>> Conflict for C<T> {
    fn conflict(&self) {}
}

Rust responds with

error[E0119]: conflicting implementations of trait `Conflict` for type `C<_>`

but the implementations don't have any intersection, and shouldn't conflict.

You can also check it out on this playground, where you can see that the conflict is also mis-detected on nightly.

[Patrick-Poitras]

@rustbot label +A-impl-trait +T-compiler

[p-avital]

Hello,

Since I haven't received much feedback for this issue, I'm just trying to prop it up a little.

Does anyone have an idea where I could try to hunt for this bug?

Thank you :)

[Patrick-Poitras]

Potential duplicate of #20400?

May be related to #31844

[p-avital]

It does seem to be a duplicate of #20400 ... So I guess no hope of that being fixed in stable anytime soon :(

I was indeed hoping this trick would let me achieve (very) limited specialization, hence the naming in the minimal example

[Ten0]

I was indeed hoping this trick would let me achieve (very) limited specialization, hence the naming in the minimal example

You have this trick that enables to work around this issue: https://stackoverflow.com/questions/40392524/conflicting-trait-implementations-even-though-associated-types-differ/40408431#40408431

I think this particular issue can be closed as duplicate.

[cdecompilador]

And how would be the workaround for a different trait, be it AsRef? Where for example you want to implement Foo for AsRef<str> and AsRef<i32>?

[Ten0]

And how would be the workaround for a different trait, be it AsRef? Where for example you want to implement Foo for AsRef<str> and AsRef<i32>?

The conflicting impl error is legitimate in this case: a struct could impl both AsRef<str> and AsRef<i32>. (In other examples of this thread, associated types actually guarantee these don't really conflict).

[Dylan-DPC]

Closing this as duplicate of #20400, and there is a valid case where the implements conflict.