-
Notifications
You must be signed in to change notification settings - Fork 51
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 more formatting traits #56
Conversation
Edit: The PR properly deals with padding and negative signs for new formatting traits, but not |
I never said it, but this is intended to fix #1 |
I can't figure out how to use
(see Travis for full output) |
The |
I'm also setting the |
Ah, note how #[cfg(feature = "std")]
#[cfg_attr(test, macro_use)]
extern crate std; Make that a direct I think the
|
This PR is no longer a breaking change -- the original That said, I think this PR is ready for review. |
src/lib.rs
Outdated
assert_eq!(&format!("{:#010b}", _1_2), "0b001/0b10"); | ||
let half_i8: Ratio<i8> = Ratio::new(1_i8, 2_i8); | ||
assert_eq!(&format!("{:b}", -half_i8), "11111111/10"); | ||
assert_eq!(&format!("{:#b}", -half_i8), "0b11111111/0b10"); |
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.
Ew -- I find it unfortunate that negative numbers are formatted this way, especially since they'll overflow if you try to parse it back, but I know it's not your doing. If you're curious, it comes from core's int_base!
casting as unsigned.
I should have mentioned before, num-complex goes through similar pains to format multiple numbers simultaneously, including |
You don't have to match that complexity (pun!) but it may show you some useful tricks. |
I would like to include this in 0.3 (#65), and notably this means we can make the breaking change you had earlier on |
TODO: eliminate heap use, write a macro for Display impls
Co-Authored-By: Josh Stone <[email protected]>
previously formatting would fail the following test case format!("{:+}", Ratio:new(-2, 1)), returning "+-2", utter nonsense. This fix adds a check for a negative sign (dash) in an intermediate string representation, removing it if found. no_std targets previously didn't support sign_plus(), but now do.
Now the correct features will be enabled when running the ci script outside of ci environments.
Use autofcg to detect if integers support exponential formatting. If so, autocfg sets the has_int_exp_fmt cfg, used in tests.
There's one more thing this doesn't support - precision. Is it worth it? Is there a way to do it that doesn't introduce much more complexity? |
Precision would really only be useful for the Exp formats, right? I think it's fine to defer that. |
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'd like the build script to be simpler, but then I think we're ready to merge!
build.rs
Outdated
&& ac.probe_expression("format!(\"{:e}\", 0_u64)") | ||
&& ac.probe_expression("format!(\"{:e}\", 0_u128)")) | ||
{ | ||
panic!("Some integer types implement *Exp traits, but not others") |
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.
This is a bit overkill, and has a tangible effect on compile times -- I measured that running the build script on current stable takes ~110ms, whereas nightly takes ~680ms. After all, each probe requires a new rustc
process invocation.
If you really want to test them all, it could be done better in one large probe expression. However, we really only care about this feature for testing purposes, so I don't think it needs to be so thorough. For that matter, the test only uses it for Rational = Ratio<isize>
, which you didn't even probe... 😉
Let's just probe for support in isize
and call it good.
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.
each probe requires a new rustc process invocation
I didn't even think about how it worked, but that makes sense.
Let's just probe for support in isize and call it good.
Sounds good.
Yep, that's right.
Agreed. I don't want to deal with it now and *Exp trait implementations for Integers hasn't landed in stable yet. I'm considering writing an RFC about how extending formatting (as this crate does) is more difficult than it needs to be because of the api. Off the top of my head, having sign_minus mean never render a sign would be nice, and there should be some way to say default precision with the |
Let's ship it! bors r+ |
Build succeeded |
fixes #1
TODO:
no_std
(does not support padding)no_std
simplify macro for formatting trait impls usingformat_args!