does &* on the Rc help
-
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
-
-
Don't get me wrong, there are definitely ambiguous situations you can get into when multiple methods are involved (if you can deref a twice and b once or a once and b twice and both are valid, which do you pick)?
-
But there are cases (such as original the one mentioned) where the answer is clearly unambiguous, and we already special case things like "there's only one impl of this trait".
- 1 more reply
New conversation -
-
-
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".
- 14 more replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.