-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Stabilize the Duration API #26818
Stabilize the Duration API #26818
Conversation
r? @aturon (rust_highfive has picked a reviewer for you, use r? to override) |
Internals discussion: https://internals.rust-lang.org/t/final-comment-period-for-the-duration-api/2325 |
I'm happy with this course of action. Could you also tag the trait implementations with the same stability tag as well? |
I'm likewise fine with this general direction, modulo the renamings discussion on the internals thread. Will try to weigh in there soon. |
I also think it's time to get this done, and don't have opinions about the fine details - seems like this type has been well-polished at this point. I'd definitely like to hear @lifthrasiir's opinions about this since rust-chrono depends on it. |
I have no particular objection, as Chrono has been a (relatively) happy user of the in-tree |
3360c04
to
f785f06
Compare
I've updated the PR to rename |
f785f06
to
0ba159c
Compare
☔ The latest upstream changes (presumably #27393) made this pull request unmergeable. Please resolve the merge conflicts. |
Can you keep deprecated versions of the old method names? We do this even for unstable APIs to ease changes in. Otherwise, I'm ready to r+ assuming everyone is on board backporting this stabilization to 1.3 (which has essentially no downside, AFAICT.) |
The downside is a deviation from our standard release process. Yes, it's a bit painful to just miss a train, but at the same time, I don't want us to get in the habit of it. |
I'm assuming I should leave the old versions unstable and then cut them out in a release or two? |
Updated |
5b31967
to
e28e707
Compare
Should I change the feature for the stable functionality? Tidy's complaining:
|
Yeah it's fine to just change the feature name of the deprecated methods to something new like |
FYI: we're going to discuss the backporting question in the core team meeting today. |
e28e707
to
9124dd9
Compare
Cool. Adjusted the feature for the old methods. |
We discussed this at the core team meeting and the consensus is that it's fine to backport this stabilization to 1.3 beta. In the future, we hope to avoid this by having more explicit "go/no go" subteam meetings around stabilization, sufficiently prior to the beta being cut. |
@bors: r+ |
📌 Commit 9124dd9 has been approved by |
@bors: r- (need to fix some benchmarks) |
This is a temporary workaround for the bugs that have been found in the implementation of PR rust-lang#26173. * pnkfelix is unavailable in the short-term (i.e. for the next week) to fix them. * When the bugs are fixed, we will turn this back on by default. (If you want to play with the known-to-be-buggy optimization in the meantime, you can opt-back in via the debugging option that this commit is toggling.)
This commit stabilizes the `std::time` module and the `Duration` type. `Duration::span` remains unstable, and the `Display` implementation for `Duration` has been removed as it is still being reworked and all trait implementations for stable types are de facto stable. This is a [breaking-change] to those using `Duration`'s `Display` implementation.
9124dd9
to
e29a62f
Compare
@bors r=aturon |
📌 Commit e29a62f has been approved by |
⌛ Testing commit e29a62f with merge f2790eb... |
💔 Test failed - auto-mac-64-opt |
@bors r=aturon |
📌 Commit b51e009 has been approved by |
This commit stabilizes the `std::time` module and the `Duration` type. `Duration::span` remains unstable, and the `Display` implementation for `Duration` has been removed as it is still being reworked and all trait implementations for stable types are de facto stable. This is a [breaking-change] to those using `Duration`'s `Display` implementation. I'm opening this PR as a platform for discussion - there may be some method renaming to do as part of the stabilization process.
This commit stabilizes the
std::time
module and theDuration
type.Duration::span
remains unstable, and theDisplay
implementation forDuration
has been removed as it is still being reworked and all traitimplementations for stable types are de facto stable.
This is a [breaking-change] to those using
Duration
'sDisplay
implementation.
I'm opening this PR as a platform for discussion - there may be some method renaming to do as part of the stabilization process.