Conflicting implementation : impl<T> From<T> for T can never conflict

[Kayanski]

Hello ! I found something that I think should be allowed in Rust.

I have 2 crates.

• trait-def with a trait definition and a first implementation :

  pub trait Test {
        type Exec;
  }
  pub struct First;
  pub struct FirstArgument;

  impl Test for First {
      type Exec = FirstArgument;
  }

• over with a second implementation of the trait for another type

  pub struct Second;
  pub struct SecondArgument;

  impl Test for Second {
      type Exec = SecondArgument;
  }

Until here, everything is alright. However, when trying to implement a simple From, things go sideways :

impl From<<First as Test>::Exec> for SecondArgument {
    fn from(value: <First as Test>::Exec) -> Self {
        Self
    }
}

It says :

error[E0119]: conflicting implementations of trait `std::convert::From<SecondArgument>` for type `SecondArgument`
   |
13 | impl From<<First as Test>::Exec> for SecondArgument {
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
   = note: conflicting implementation in crate `core`:
           - impl<T> std::convert::From<T> for T;

This is a very simplified example and I can't just implement From for SecondArgument for unrelated reasons.

I know you have to be careful about implementations of From with traits, but here everything is set in stone, I'm not using generic types. One argument could be that <First as Test>::Exec could be equal to Second Argument, but this is not possible because trait-def can't import the over crate for circular dependency reasons.

I have this repo that illustrates the situation (https://github.com/Kayanski/rust-trait-impl-reproduce)

[saethlin]

@rust-lang/types is it correct that the above scenario should be allowed if the solver were clever enough?

[lcnr]

yes it should 😊 it's difficult though as we have to avoid cyclic reasoning. it's currently not a main priority of the types team (as it can be avoided by manually normalizing when writing the impl), but definitely something we'd like to fix at some point

closing as a duplicate of #85576