-
-
Notifications
You must be signed in to change notification settings - Fork 352
StatusCode TryFrom and PartialEq with integer types #451
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
base: master
Are you sure you want to change the base?
Conversation
|
Asked about the error mentioned above and got a helpful, quick answer here: https://users.rust-lang.org/t/whats-so-special-about-the-i32-type-here/52613/3 So its known limitation of the compiler and i32 conversions need to be implemented to handle the i32 fallback for non-inferred integer literals. Inference no longer happens with the multiple TryFrom impls of this PR. |
f1a1ff6 to
cdbf9a5
Compare
cdbf9a5 to
6fbf565
Compare
I think there is no relevant conflict. #442 has Also, I think this change looks good in itself (but I'm not a maintainer of this crate). |
|
Okay, thanks. That was the kind of sanity check on this PR I was hoping for. |
robjtede
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i think the reasoning to add these impls is sound enough
As suggested in #230, I added
TryFrom<usize>,<u32>and<u64>andFrom<StatusCode>for the same integer types, and re-implemented<u16>with the same macro. Oddly enough, if I stop with unsigned types, then previously working doctests for response::{Response, Builder} start failing with the following:...
which seems almost more like an obscure rustc or stdlib bug? (Fails on MSRV 1.39.0 as well as a recent nightly)(edit: see comment below). As this was done withmacro_rules!, its easy to extend to the signed typesi16,i32,isize, andi64types to avoid the above issue. Since its implemented viau16::try_fromthere is nothing particularly more unusual about including support for the signed types: negative values are just another case ofInvalidStatusCode.Also added bi-directional
PartialEqfor all of these integer types. This makes it sou16doesn't have any particular favor in the public interface other then the existingStatusCode::from_u16andas_u16. If a user sticks toTryInto,FromandPartialEqthenu16(andNonZeroU16) is just a private implementation detail.The PR includes some misc related test and doc improvements.
Given the warning of the about mentioned compile error, I would not suggest merging this for release in a patch release like 0.2.2. It warrants at least a MINOR bump 0.3.0 or 1.0.0.
Fixes #230