Conflicting implementations

[OptimisticPeach]

@Austin

Also apologies for lack of formatting, I can never remember how to get this forum to format code, and can't find any help about it either.

Forum Code Formatting and Syntax Highlighting

To format code in this forum you need to surround the code with three backticks (```). For example, typing this... ``` fn main() { println!() } ``` ...will be rendered as highlighted Rust code, like so: fn main() { println!() } You can also tell the forum software which language you're using by adding the language after the opening backticks. ```cpp #include <iostream> int main() { std::cout << "Hello World!"; } ``` Will appear with highlighting as: #include <iostream> int main(…

It's pinned but it gets unpinned whenever you take a look at it. An easy way to find it is to Search -> Only return topics/posts -> dropdown -> are pinned.

---

To your actual question:

There is a question which will determine how to fix this: do you intend on using the capabilities of std::error::Error?

• If so, you can leverage the fact that stdlib does exactly what you're trying to do and bounce off of that: impl one and impl two.

  pub struct FooError<'a> {
      error: Box<dyn ErrorTrait + 'a>,
  }
  
  impl<'a, T: 'a> From<T> for FooError 
      where Box<dyn ErrorTrait + 'a>: From<T> {
      fn from(x: T) -> Self {
          Self { error: x.into() }
      }
  }
  

• If not, then you can rely on the fact that any T: Error must also be Display, and just work off of that:

  // Your original FooError definition
  impl<T: Display> From<T> for FooError {
      fn from(x: T) -> Self {
          Self { error: format!("{}", x) }
      }
  }
  

  Note, however, that this will work for anything which is display.

One thing which might work is to combine the approaches:

// Your original FooError definition
impl<'a, T: 'a> From<T> for FooError 
    where Box<dyn ErrorTrait + 'a>: From<T> {
    fn from(x: T) -> Self {
        Self {
            error: format!("{:?}", x.into())
        }
    }
}

However if you're performing this from call very often, it might be slightly slower, due to the use of trait objects.

---

@Austin

Is there no way to tell the compiler that I'm happy to take the risk of my code being broken in the future?

No, by design. In theory everyone follows semver, and it's not a semver-breaking change to implement a trait (usually, ignoring special things like !Send [when dealing with multithreaded code] and Drop [when dealing with unions]).