chrono
chrono copied to clipboard
Add padding width
Fixes #1663
Codecov Report
Attention: Patch coverage is 96.80851% with 6 lines in your changes missing coverage. Please review.
Project coverage is 91.13%. Comparing base (
fa957cc) to head (d89f8f9).
| Files with missing lines | Patch % | Lines |
|---|---|---|
| src/format/formatting.rs | 85.36% | 6 Missing :warning: |
Additional details and impacted files
@@ Coverage Diff @@
## main #1672 +/- ##
==========================================
+ Coverage 91.06% 91.13% +0.06%
==========================================
Files 37 37
Lines 17454 17565 +111
==========================================
+ Hits 15895 16007 +112
+ Misses 1559 1558 -1
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
🚀 New features to boost your workflow:
- ❄ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
Hmm the codecov/project task seams to be stuck. Can someone have a look?
In general this PR should be a proposal how it whould look like if we add the padding width to the Numeric enum and not to the Pad enum where it whould belong to. My conclusion is:
Advantages:
- The API might be stable as the Numeric enum is #[non_exhaustive]
Drawbacks:
- The API only works with dynamic memory allocation
- The work with the padding width is cumbersome and needs more API changes that have to be removed when the padding width is moved to the Pad enum in the future
I think we should postpone the changes untill we can add the padding with to where it should be so that we can implement it in a minimal invasive and maximal compatible way.
I think we should postpone the changes untill we can add the padding with to where it should be so that we can implement it in a minimal invasive and maximal compatible way.
Okay, but I have no concrete plans nor much motivation to work on chrono 0.5, so that might mean postponing more or less indefinitely.