libstd: Refactor Duration. #16626
Merged
libstd: Refactor Duration. #16626
+200
−279
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This changes the internal representation of `Duration` from
days: i32,
secs: i32,
nanos: u32
to
secs: i64,
nanos: i32
This resolves rust-lang#16466. Some methods now take `i64` instead of `i32` due
to the increased range. Some methods, like `num_milliseconds`, now
return an `Option<i64>` instead of `i64`, because the range of
`Duration` is now larger than e.g. 2^63 milliseconds.
|
2^63 milliseconds is just shy of 300 million years. Do we really need to support the full range that i64 seconds gives us? It might be a better API to just restrict |
|
We could restrict it to |
|
As I said on the previous PR, I think it's acceptable for |
This enables `num_milliseconds` to return an `i64` again instead of `Option<i64>`, because it is guaranteed not to overflow. The Duration range is now rougly 300e6 years (positive and negative), whereas it was 300e9 years previously. To put these numbers in perspective, 300e9 years is about 21 times the age of the universe (according to Wolfram|Alpha). 300e6 years is about 1/15 of the age of the earth (according to Wolfram|Alpha).
|
The failures don’t seem to be related to the changes ... is there something I should fix? |
| assert!(Duration::days(MAX_DAYS).checked_add(&Duration::seconds(86400)).is_none()); | ||
| assert_eq!(Duration::milliseconds(i64::MAX - 1).checked_add(&Duration::microseconds(999)), | ||
| Some(Duration::milliseconds(i64::MAX - 2) + Duration::microseconds(1999))); | ||
| assert!(Duration::milliseconds(i64::MAX).checked_add(&Duration::microseconds(1000)).is_none()); |
There was a problem hiding this comment.
This line is too long, according to make tidy.
|
The failure was
This is indeed something you need to fix. |
bors
added a commit
that referenced
this pull request
Aug 28, 2014
This changes the internal representation of `Duration` from
days: i32,
secs: i32,
nanos: u32
to
secs: i64,
nanos: i32
This resolves #16466. Note that `nanos` is an `i32` and not `u32` as suggested, because `i32` is easier to deal with, and it is not exposed anyway. Some methods now take `i64` instead of `i32` due to the increased range. Some methods, like `num_milliseconds`, now return an `Option<i64>` instead of `i64`, because the range of `Duration` is now larger than e.g. 2^63 milliseconds.
A few remarks:
- Negating `MIN` is impossible. I chose to return `MAX` as `-MIN`, but it is one nanosecond less than the actual negation. Is this the desired behaviour?
- In `std::io::timer`, some functions accept a `Duration`, which is internally converted into a number of milliseconds. However, the range of `Duration` is now larger than 2^64 milliseconds. There is already a FIXME in the file that this should be addressed (without a ticket number though). I chose to silently use 0 ms if the duration is too long. Is that right, as long as the backend still uses milliseconds?
- Negative durations are not formatted correctly, but they were not formatted correctly before either.
bors
added a commit
that referenced
this pull request
Aug 31, 2014
This changes the `Add` and `Sub` implementations for `Timespec` introduced in #16573 to use `Duration` as the time span type instead of `Timespec` itself, as [suggested](#16573 (comment)) by @sfackler. This depends on #16626, because is uses `Duration::seconds(i64)`, whereas currently `Duration::seconds` takes an `i32`.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This changes the internal representation of
Durationfromto
This resolves #16466. Note that
nanosis ani32and notu32as suggested, becausei32is easier to deal with, and it is not exposed anyway. Some methods now takei64instead ofi32due to the increased range. Some methods, likenum_milliseconds, now return anOption<i64>instead ofi64, because the range ofDurationis now larger than e.g. 2^63 milliseconds.A few remarks:
MINis impossible. I chose to returnMAXas-MIN, but it is one nanosecond less than the actual negation. Is this the desired behaviour?std::io::timer, some functions accept aDuration, which is internally converted into a number of milliseconds. However, the range ofDurationis now larger than 2^64 milliseconds. There is already a FIXME in the file that this should be addressed (without a ticket number though). I chose to silently use 0 ms if the duration is too long. Is that right, as long as the backend still uses milliseconds?