Miss Dada  🏳️‍⚧️

ahh

yeah it makes more sense when you realise it's invoking a function of two arguments, and Deref doesn't mean that fn will try to find a common deref target to make the type system happy

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