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
-
when it's trying to coerce &foo to &****foo, there is no such two step process, it's just an additional transform inference may attempt to apply, and it only manages to apply it in cases that are not too generic
Right, my point is just that it gives up too easily. There are plenty of cases that could work today that are 100% unambiguous that it gives up on (like literally any other impl existing even if the type involved cannot possibly be deref'd to).
-
-
I also think we could just have standard rules for the ambiguous cases, but there's not a ton of point in debating that on Twitter, I need to write an RFC if I want it to change
-
My main point I guess is that a lot of this is arbitrary. https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=3e3a0bf4b92b481282a1ec6061b12be7 … is just as ambiguous if not moreso than the other cases I've mentioned, but we're fine with arbitrarily picking one even if the code doesn't obviously imply which is picked
End of conversation
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.