Rewrite <Duration as fmt::Display>::fmt()

[lilyball]

Implement new formatting behavior that is smarter about the unit it uses
and handles precision.

format!("{}", Duration::new(0, 1_001)) // 1.001µs
format!("{}", Duration::new(0, 1_001_001)) // 1.001ms
format!("{:.6}", Duration::new(0, 1_001_001)) // 1.001001ms
// etc

The default is variable precision up to 3 decimals. No unit higher than
seconds are used.

See rust-lang/rfcs#1121 for more information.

[lilyball]

r? @alexcrichton

[rust-highfive]

r? @nikomatsakis

(rust_highfive has picked a reviewer for you, use r? to override)

[alexcrichton]

Can you wrap this (and the remaining lines) to 100 characters? Although the style guide says 100 max it's more important to follow the style of the surrounding code.

[lilyball]

I'm not sure what you mean. You're asking me to wrap it to 100, which is already the limit it's wrapped at. Did you mean to ask for a different line length?

FWIW, I typically wrap doc comments at 79 but leave code at 100. I didn't wrap this to 79 because it's not a doc comment.

[alexcrichton]

Oh oops sorry I meant wrap to 80!

[lilyball]

I just tried wrapping to 80, and the resulting code is significantly harder to read, because a bunch of lines that fit comfortably with 100 now have to be wrapped awkwardly. The code here is indented more than the rest of the module, so they already don't have as much space.

I also don't understand why you think it's important to wrap this to 80 characters. You say it's important to follow the style of the surrounding code, but I don't see any justification at all for that other than the fact that you wrote the surrounding code and you personally prefer 80 characters. If someone else had written this file, I suspect you wouldn't think it's so important. In fact, I know you wouldn't, because prior to 556e76b this file was written for a line limit of 100.

In general, following the style of the surrounding code is a sensible policy when the project does not have a well-defined style. And even when it does, it still makes sense with small changes to preserve the cohesive style. But rust-lang/rust has a (reasonably-)well-defined style, and this is a significant chunk of new functionality (as opposed to individual lines here and there). And since the readability of this code suffers significantly with the shorter line length, I don't think it makes sense to restrict it like that.

[alexcrichton]

This method is actually exposed as f.pad(buf_str), although another option here would also be to use buf_str.fmt(f)

[lilyball]

We actually can't use f.pad(buf_str), because it interprets precision as the maximum width of the string to print, but we're using precision here for a different purpose. I'm actually kind of surprised the formatting code doesn't have any way of changing the flags, and I decided not to attempt to hack it with a write!() call that uses a caller-supplied width because that discards alignment and fill.

[alexcrichton]

This seems quite complicated, and perhaps not getting a lot of bang for our buck, would it be possible to use something simpler which perhaps has an intermediate buffer allocation? It's quite unlikely that the fmt::Display implementation for Duration is going to be at the middle of a tight loop, and otherwise this code is somewhat difficult to follow as there's a lot going on.

[lilyball]

I don't think using a buffer allocation would simplify it, that would just end up writing to a Vec<u8> instead of a Cursor<&mut [u8]>, but the code otherwise would be the same. The complexity here comes just from the fact that I'm writing to an intermediate buffer at all, which I want to preserve because I think we should support padding/alignment on all stdlib fmt::Display implementations. The fmt API doesn't currently expose the necessary tools to do this, but if nobody else deals with that, I'm planning on at some point trying to figure out the right way to fix that so we can support padding properly.

Some of the complexity also comes from the fact that the flt2dec code is all private. I'd love to be able to explicitly call into that code with integral values for the various components, but for now I'm using the hack documented in this code. I figure I'll take a look again in the future when our new float formatting code is in place.

I do agree that this is a bit complicated. It ended up being more complicated than I had first expected. Part of that is due to the need to round the decimal when not printing at full precision (this rounding is the main reason I fell back to using the float serializing).

[lilyball]

@alexcrichton Sorry for the delayed response, but I've now responded to your review comments.

[lilyball]

@alexcrichton r?

[alexcrichton]

I think we may want to hold off on this until a decision on #26818 is reached, as that PR is deleting the display implementation.

[sfackler]

It's only deleting the impl under the assumption that this wasn't good to go. If we think we're happy with this Display logic being used for all time, then I'll update my PR to not delete it.

[bors]

☔️ The latest upstream changes (presumably #26818) made this pull request unmergeable. Please resolve the merge conflicts.

[steveklabnik]

So, with #26818 merged, what's the status of this PR?

[lilyball]

Good question. I'd really like to see this get merged in. Obviously there's conflicts that need resolving now, but I haven't touched it as there has been no indication as to whether it will be accepted.

[alexcrichton]

The libs team decided to close this during triage yesterday, more info can be found in my comment on #29146.