Coherence violation when inherent method is added to type

[ebfull]

It seems that because inherent methods are always called before trait methods, when a dependency adds an inherent method to a struct (which should be a backwards-compatible change to its API requiring no major semver bump) your code that was previously calling a trait method on that struct will (silently) switch to calling the inherent method.

As an example, I could make an extension trait for Option defining a method named foo, publish my_cool_crate, and then if an inherent method named foo is added to Option in a new version of core then my crate can suddenly behave differently despite merely upgrading my Rust compiler. Perhaps it could also fail to compile (like if the signature is "compatible" at the callsite but then a typechecking error happens elsewhere).

I'm not sure if this is a coherence violation or not, or whether this has already been observed/discussed elsewhere. (Had no luck when I searched for github issues about it.)

[jonas-schievink]

This is a well-known property of inherent impls in general (they're preferred over trait impls). It doesn't violate coherence since coherence only reasons about overlapping impls themselves, not items defined within them (which can always be referred to explicitly).

[ebfull]

I'm not sure how else to title this issue, suggestions welcome.

Are there other known examples in the language where presumably reverse-compatible API changes can actually break or change the behavior of downstream code? I don't know why, but I had an expectation that the language was designed to ensure these kinds of things can't happen.

[cramertj]

In general, breakages due to inference (method inference, trait inference, type inference, etc.) are allowed under our backwards-compatibility guidelines. Without this, things like defining a new type, trait, or adding a method to anything anywhere would be a breaking change.