-
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
feat: reinterpret precision
field for strings
#34544
feat: reinterpret precision
field for strings
#34544
Conversation
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @aturon (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see the contribution instructions for more information. |
Thanks for the PR @3Hren! While this does change behavior and could be a breaking change, to me this seems like the correct interpretation of the documentation as well so I'd consider it a bug fix. I agree that this is the more correct way to do this, and I like the size of the patch as well! Would it be possible to clarify in the documentation a bit when this case arises this is what happens? cc @rust-lang/libs, others have thoughts on a change like this? |
This seems reasonable to me. I'm not too worried about it breaking things. |
sgtm |
@alexcrichton thanks for reviewing this PR! Just updated the docs, please take a look. Should I squash commits? |
Looks good to me, thanks! And yeah I'd recommend squashing. |
This commit changes the behavior of formatting string arguments with both width and precision fields set. Documentation says that the `width` field is the "minimum width" that the format should take up. If the value's string does not fill up this many characters, then the padding specified by fill/alignment will be used to take up the required space. This is true for all formatted types except string, which is truncated down to `precision` number of chars and then all of `fill`, `align` and `width` fields are completely ignored. For example: `format!("{:/^10.8}", "1234567890);` emits "12345678". In the contrast Python version works as the expected: ```python >>> '{:/^10.8}'.format('1234567890') '/12345678/' ``` This commit gives back the `Python` behavior by changing the `precision` field meaning to the truncation and nothing more. The result string *will* be prepended/appended up to the `width` field with the proper `fill` char. However, this is the breaking change. Also updated `std::fmt` docs about string precision. Signed-off-by: Evgeny Safronov <division494@gmail.com>
bcd0e44
to
ede39ae
Compare
Done! |
@alexcrichton should I do anything else here? I see that this PR suddenly became unmergable for some reasons. |
@3Hren nah you're good, it'll take a moment for @rust-lang/libs to convene about this most likely, but it's all on our end now at this point! I'll be sure to let you know if we need anything else. This looks to me like it's still mergeable, but if that happens it may just indicate that this needs to be rebased and force-pushed to your branch. |
📌 Commit ede39ae has been approved by |
⌛ Testing commit ede39ae with merge ac8b776... |
💔 Test failed - auto-win-gnu-32-opt-rustbuild |
⌛ Testing commit ede39ae with merge 0c737f1... |
💔 Test failed - auto-win-msvc-64-cargotest |
@bors: retry
On Tue, Jul 19, 2016 at 9:54 AM, bors notifications@github.com wrote:
|
⌛ Testing commit ede39ae with merge aa501e2... |
💔 Test failed - auto-win-msvc-64-opt |
@bors: retry On Tue, Jul 19, 2016 at 12:38 PM, bors notifications@github.com wrote:
|
He hates me |
⌛ Testing commit ede39ae with merge 4e8750d... |
💔 Test failed - auto-win-gnu-32-opt-rustbuild |
@bors: retry On Tue, Jul 19, 2016 at 9:10 PM, bors notifications@github.com wrote:
|
⌛ Testing commit ede39ae with merge 3329c1d... |
💔 Test failed - auto-linux-64-cross-freebsd |
@bors: retry
On Wed, Jul 20, 2016 at 6:23 AM, bors notifications@github.com wrote:
|
⌛ Testing commit ede39ae with merge 372472b... |
💔 Test failed - auto-win-gnu-32-opt-rustbuild |
@bors: retry On Wed, Jul 20, 2016 at 5:31 PM, bors notifications@github.com wrote:
|
⌛ Testing commit ede39ae with merge de06ee9... |
💔 Test failed - auto-win-gnu-64-opt |
Never seen that error before... Assuming spurious though as it seems unrelated! @bors: retry |
…r-strings, r=alexcrichton feat: reinterpret `precision` field for strings This commit changes the behavior of formatting string arguments with both width and precision fields set. Documentation says that the `width` field is the "minimum width" that the format should take up. If the value's string does not fill up this many characters, then the padding specified by fill/alignment will be used to take up the required space. This is true for all formatted types except string, which is truncated down to `precision` number of chars and then all of `fill`, `align` and `width` fields are completely ignored. For example: `format!("{:/^10.8}", "1234567890);` emits "12345678". In the contrast Python version works as the expected: ```python >>> '{:/^10.8}'.format('1234567890') '/12345678/' ``` This commit gives back the `Python` behavior by changing the `precision` field meaning to the truncation and nothing more. The result string *will* be prepended/appended up to the `width` field with the proper `fill` char. __However, this is the breaking change, I admit.__ Feel free to close it, but otherwise it should be mentioned in the `std::fmt` documentation somewhere near of `fill/align/width` fields description.
💔 Test failed - auto-linux-musl-64-opt |
@bors: retry
On Thu, Jul 21, 2016 at 10:57 AM, bors notifications@github.com wrote:
|
⌛ Testing commit ede39ae with merge ea06463... |
💔 Test failed - auto-win-gnu-32-opt |
@bors: retry sorry for the number of retries... On Thu, Jul 21, 2016 at 11:51 AM, bors notifications@github.com wrote:
|
…r-strings, r=alexcrichton feat: reinterpret `precision` field for strings This commit changes the behavior of formatting string arguments with both width and precision fields set. Documentation says that the `width` field is the "minimum width" that the format should take up. If the value's string does not fill up this many characters, then the padding specified by fill/alignment will be used to take up the required space. This is true for all formatted types except string, which is truncated down to `precision` number of chars and then all of `fill`, `align` and `width` fields are completely ignored. For example: `format!("{:/^10.8}", "1234567890);` emits "12345678". In the contrast Python version works as the expected: ```python >>> '{:/^10.8}'.format('1234567890') '/12345678/' ``` This commit gives back the `Python` behavior by changing the `precision` field meaning to the truncation and nothing more. The result string *will* be prepended/appended up to the `width` field with the proper `fill` char. __However, this is the breaking change, I admit.__ Feel free to close it, but otherwise it should be mentioned in the `std::fmt` documentation somewhere near of `fill/align/width` fields description.
It’s all right. Just robots dominating :D |
// case where the maximum length will matter. | ||
// string being formatted. | ||
let s = if let Some(max) = self.precision { | ||
// If our string is longer that the precision, then we must have |
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.
s/that/than/
This commit changes the behavior of formatting string arguments with both width and precision fields set.
Documentation says that the
width
field is the "minimum width" that the format should take up. If the value's string does not fill up this many characters, then the padding specified by fill/alignment will be used to take up the required space.This is true for all formatted types except string, which is truncated down to
precision
number of chars and then all offill
,align
andwidth
fields are completely ignored.For example:
format!("{:/^10.8}", "1234567890);
emits "12345678". In the contrast Python version works as the expected:This commit gives back the
Python
behavior by changing theprecision
field meaning to the truncation and nothing more. The result string will be prepended/appended up to thewidth
field with the properfill
char.However, this is the breaking change, I admit. Feel free to close it, but otherwise it should be mentioned in the
std::fmt
documentation somewhere near offill/align/width
fields description.