Improve method selection to make short-circuiting clear #1534
Comments
adetaylor
added a commit
to adetaylor/reference
that referenced
this issue
Jan 30, 2025
This section of the reference has been oversimplistic for some time (rust-lang#1018 and rust-lang#1534) and various rewrites have been attempted (e.g. rust-lang#1394, rust-lang#1432). Here's another attempt! My approach here is: * Stop trying to keep it short and concise * Document what actually happens in the code, step by step This does result in a long explanation, because we're trying to document nearly 2400 lines of code in `probe.rs`, but doing otherwise feels as though we'll continue to run into criticisms of oversimplification. This rewrite documents the post-arbitrary-self-types v2 situation, i.e. it assumes rust-lang/rust#135881 has landed. We should not merge this until or unless that lands. This PR was inspired by discussion in rust-lang#1699. If we go ahead with this approach, rust-lang#1699 becomes irrelevant. There was also discussion at rust-lang/cargo#15117 (comment)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Method resolution has two steps. We collect a list of types, then we go through that list and, for each type, look to see whether there's one or more matching methods. If we find multiple matching trait methods, that's an error. But otherwise, we stop if we find one.
What we don't do is continue down the list of types after finding a matching method. In PR #1394 this was brought up. We weren't happy with the fix, but this is something we should think about when reworking this language.
See also:
cc @ehuss
The text was updated successfully, but these errors were encountered: