How is there a conflicting implementation of `From` when using a generic type?

The problem here is someone may implement Storage so that the From impl you have written overlaps with the impl in the standard library of impl<T> From<T> for T (that is, anything can be converted to itself).

Specifically,

struct Tricky;

impl Storage for Tricky {
    type Error = MyError<Tricky>;
}

(The set-up here means this doesn’t actually compile—MyError<Tricky> is infinitely large—but that error is unrelated to the reasoning about impls/coherence/overlap, and indeed small changes to MyError can make it compile without changing the fundamental problem, e.g. adding a Box like StorageProblem(Box<S::Error>),.)

If we substitute Tricky in place of S in your impl, we get:

impl From<MyError<Tricky>> for MyError<Tricky> {
    ...
}

This impl exactly matches the self-conversion one with T == MyError<Tricky>, and hence the compiler wouldn’t know which one to choose. Instead of making an arbitrary/random choice, the Rust compiler avoids situations like this, and thus the original code must be rejected due to this risk.

This coherence restriction can definitely be annoying, and is one of reasons that specialisation is a much-anticipated feature: essentially allows manually instructing the compiler how to handle overlap… at least, one of the extensions to the current restricted form allows that.

Leave a Comment