-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Add PartialEq and PartialOrd for NonZeroInt to Int #72405
Conversation
r? @kennytm (rust_highfive has picked a reviewer for you, use r? to override) |
r? @Amanieu |
IMO if |
I'm happy to add that; I wasn't sure if there were any especial concerns related to implementing traits on primitive types in the standard library |
dfe8a23
to
0ccaa56
Compare
Rebased; added symmetric operators |
The job Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
Build failures seem unrelated to this PR? Unless type inference looks "through" trait implementations like this, which I thought it didn't. In any case, if that is related to this PR, then creating the int <=> nonzero impls like this might be considered a breaking change, right? |
Hmm. Confirmed that this change does result in that breakage, probably because the type of |
@Lucretiel Ping from triage! This needs to get the CI fixed. Or if you feel the breakage is acceptable, change the test itself and ask for a crater run if necessary. Thanks! |
Oh— I didn't think I was able to make that assessment. I'd like to ask for someone from the libraries team to determine if this breakage is acceptable. If it is up to me, I'd say that it is acceptable, because I had the impression that operators couldn't be used for type inference in this way. |
☔ The latest upstream changes (presumably #72717) made this pull request unmergeable. Please resolve the merge conflicts. |
@Lucretiel what's the status of this PR? |
The status is that a decision needs to be made about whether this constitutes a breaking change because of the apparent effect it has on type inference on integer primitives and I don't feel even remotely qualified to assess that. |
Let's re-assign from the libs. |
I can fix the merge conflicts in the meantime; I was holding off because I was getting a vibe that this was going to end up rejected due to compatibility concerns and I wanted to see if there was a consensus there first. |
@Lucretiel In case, if you get no response for a while, you can ask the team to review on the Zulip stream: https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs |
@JohnTitor excellent, thanks for the heads up |
Hmm, let’s see if we can get an idea of how much breakage there is in the wild. @craterbot check |
🚨 Error: missing start toolchain 🆘 If you have any trouble with Crater please ping |
Guess we need to get the build green first 😄 |
Yup I'll take care of it tonight |
0ccaa56
to
3948c65
Compare
Done |
CI is still red. Needs to fix the build. @Lucretiel |
@Lucretiel any updates on this? |
Nope, sorry to be so periodic about this, been busy with other things. Will get to refactoring as soon as I'm able. |
☔ The latest upstream changes (presumably #76422) made this pull request unmergeable. Please resolve the merge conflicts. |
@Lucretiel Ping from triage, any updates? |
@Lucretiel Thanks for the contribution. Sadly I have to close this due to inactivity. If you wish and feel like you have the time to contribute, you can open a new PR with the change and we can take it from there. |
Propose adding
PartialEq
andPartialOrd
to theNonZeroInt
types to compare to their inner types. Seems like a pretty obvious change, but I'm obviously open to any feedback or suggestions.I'd also like to implement
PartialEq<NonZeroInt> for Int
, but I wasn't sure what the implications were for implementing traits on primitive types like that.Retry of #70855