-
Notifications
You must be signed in to change notification settings - Fork 12.5k
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
Surprising non-idempotent behavior on {integer}
inference + method resolution
#121453
Comments
This comment was marked as resolved.
This comment was marked as resolved.
I observed more wired behaviors and wondered if it is actually a feature.
https://godbolt.org/z/f4hn9K9cn ![]()
![]() ![]() |
If |
I guess the type infer cause first |
In the Zulip link from the description, errs has already given a clear explanation for the cause (see also someone on X.) The only question is whether such behavior is optimal. |
This comment was marked as resolved.
This comment was marked as resolved.
I don't believe this is possible to fix with a lot of fallout. See CI failures on #121459, we can't even bootstrap core for example. |
I don't expect much real-world code to include this pattern, so it may not be worthwhile to make changes to inference. Will it be a good idea to have a warn-by-default lint about such trait impl on numeric types with ambiguous names with inherent methods? |
Could this be changed over an edition? |
Closing this as a duplicate of #99405, please continue discussion in that issue. |
Excerpt from Zulip (originally https://rust-lang.zulipchat.com/#narrow/stream/144729-t-types/topic/Question.20from.20t-spec/near/422487076):
Output (playground):
I find and repost the above code snippets from Zulip to a discussion group, and someone think it to be a counterintuitive oddity which deserves more discussion. Open the issue to see if there is anything can be improved (like adding a warning).
The text was updated successfully, but these errors were encountered: