-
Notifications
You must be signed in to change notification settings - Fork 13.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Trait method takes precedence over inherent method on ambiguous numeric type #99405
Comments
One thing that fell through the tracks was one of my suggestions (to @workingjubilee) regarding a potential complete replacement for inherent impls on builtin types, that still has a lot of the same user-facing properties (i.e. those methods take precedence over methods defined by traits instead of being ambiguous with them). The advantage is that if (original motivation was making |
Hello! It didn't quite fall through the tracks so much as I wound up kinda busy at an inopportune time. I hope to take a closer look at this soon. 👀 |
Dump the source into LLVM IR using command
And it calls
To be simple, it does two things:
Other observations: Case 1:
This snippet outputs Case 2:
This snippet does not compile:
Case 3:
This snippet outputs This behavior really surprises me, and is there any progress on this? |
…r=<try> [crater] Assemble method candidates for numerical infer vars Gauging the fallout of not allowing traits to shadow inherent methods on numerical types. cc rust-lang#99405 r? `@ghost`
See also discussions in #121453. |
This is arguably quite confusing:
Ouput:
So the first
x.abs()
call resolves to the trait method, which is then used to influence type inference to makex
ani64
. Withx
beingi64
, the secondx.abs()
call calls the inherent method.@rustbot label T-compiler, T-lang, A-traits, A-typesystem
The text was updated successfully, but these errors were encountered: