Miss Dada  🏳️‍⚧️

Nah, it can pick one. It's just because traits are involved (and there are multiple deref targets to choose from, though it could just pick the first in the chain tbh) https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=00257fc8db0914a33c6e000a038111e8 …

basically, http://foo.bar () - style autoderef works in generic situations, but the kind of autoderef where &*** is automatically applied to things to coerce them is far more limited: if it's generic (or even if relying too heavily on inference) it won't work

Yup, which is kinda silly because the same rules used to decide which type is the receiver of `.bar` can be applied whenever `&` is used for argument passing

not really: in the former situation you're looking for a type -- any type -- with the method "bar". it's a simple linear search down the deref chain in the latter you're looking for a type which satisfies certain constraints, which is much trickier

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".