Miss Dada  🏳️‍⚧️

a == b is sugar for PartialEq::eq(&a, &b), not a.eq(&b). These are different, and more importantly the former situation can't be figured out as a simple search

Assuming `a` does not have an inherent method named `eq`, I don't think those resolve differently at all. They certainly both fail in the same way with the code mentioned

Oh, sorry, the problem here is b not a, my bad. Actually in that case it's far more stark, we're not looking for a method at all, we're looking to see if &b satisfies a certain trait

yes, we could implement stuff here to make it better, but "does b or *(n)b have a method foo" is different from "does b or &*(n)b work as T in PartialEq<T> for str".

https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=be5ff1a4c279c3f05e1d4607391623ec … is a more concrete explanation of what I mean. `Self` is special cased in more than just dot form

I don't understand how that's special casing self types? Deref coercions give up pretty easily, that's the root of this. Here it's giving up on the UFCS form only, with the autoderef working: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=c0197afb83c273b0f4181ddef6fd0cf6 …

and here it fails on the .eq() form because of the ambiguity, because the way autoderef works is that it drills down to find the *first* method that matches the *name*, and then tries resolving everything else https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=f0c1f17bc65fa5bb84f6fd9e3fab8002 …

it's not the same rules. when it comes to finding .method(), it searches for the first .method() it can find, locks that down, and uses that to inform inference for the arguments.