Skip to content
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

Merged
merged 6 commits into from
Aug 11, 2015
Merged

Conversation

sfackler
Copy link
Member

@sfackler sfackler commented Jul 6, 2015

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.

@sfackler sfackler added the T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. label Jul 6, 2015
@rust-highfive
Copy link
Collaborator

r? @aturon

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

@sfackler
Copy link
Member Author

sfackler commented Jul 6, 2015

@alexcrichton alexcrichton added the I-needs-decision Issue: In need of a decision. label Jul 6, 2015
@alexcrichton
Copy link
Member

I'm happy with this course of action. Could you also tag the trait implementations with the same stability tag as well?

@aturon
Copy link
Member

aturon commented Jul 7, 2015

I'm likewise fine with this general direction, modulo the renamings discussion on the internals thread. Will try to weigh in there soon.

@brson
Copy link
Contributor

brson commented Jul 7, 2015

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.

@lifthrasiir
Copy link
Contributor

I have no particular objection, as Chrono has been a (relatively) happy user of the in-tree Duration type. I would have to adjust Chrono to deal with the removal of Display implementation but I can deal with it.

@sfackler
Copy link
Member Author

sfackler commented Aug 4, 2015

I've updated the PR to rename secs to as_secs and extra_nanos to subsec_nanos in response to feedback from the internals discussion.

@sfackler sfackler force-pushed the duration-stabilization branch from f785f06 to 0ba159c Compare August 4, 2015 06:20
@bors
Copy link
Contributor

bors commented Aug 5, 2015

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

@aturon
Copy link
Member

aturon commented Aug 7, 2015

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.)

@steveklabnik
Copy link
Member

(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.

@sfackler
Copy link
Member Author

sfackler commented Aug 7, 2015

I'm assuming I should leave the old versions unstable and then cut them out in a release or two?

@sfackler
Copy link
Member Author

sfackler commented Aug 7, 2015

Updated

@sfackler sfackler force-pushed the duration-stabilization branch 2 times, most recently from 5b31967 to e28e707 Compare August 7, 2015 23:21
@sfackler
Copy link
Member Author

sfackler commented Aug 8, 2015

Should I change the feature for the stable functionality? Tidy's complaining:

error: feature 'duration' is both stable and unstable

@alexcrichton
Copy link
Member

Yeah it's fine to just change the feature name of the deprecated methods to something new like duration_old.

@aturon
Copy link
Member

aturon commented Aug 10, 2015

FYI: we're going to discuss the backporting question in the core team meeting today.

@sfackler sfackler force-pushed the duration-stabilization branch from e28e707 to 9124dd9 Compare August 10, 2015 17:50
@sfackler
Copy link
Member Author

Cool. Adjusted the feature for the old methods.

@aturon
Copy link
Member

aturon commented Aug 10, 2015

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.

@aturon
Copy link
Member

aturon commented Aug 10, 2015

@bors: r+

@bors
Copy link
Contributor

bors commented Aug 10, 2015

📌 Commit 9124dd9 has been approved by aturon

@aturon aturon added beta-nominated Nominated for backporting to the compiler in the beta channel. beta-accepted Accepted for backporting to the compiler in the beta channel. labels Aug 10, 2015
@aturon aturon removed the I-needs-decision Issue: In need of a decision. label Aug 10, 2015
@sfackler
Copy link
Member Author

@bors: r-

(need to fix some benchmarks)

pnkfelix and others added 5 commits August 10, 2015 20:04
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.
@sfackler sfackler force-pushed the duration-stabilization branch from 9124dd9 to e29a62f Compare August 11, 2015 00:04
@sfackler
Copy link
Member Author

@bors r=aturon

@bors
Copy link
Contributor

bors commented Aug 11, 2015

📌 Commit e29a62f has been approved by aturon

@bors
Copy link
Contributor

bors commented Aug 11, 2015

⌛ Testing commit e29a62f with merge f2790eb...

@bors
Copy link
Contributor

bors commented Aug 11, 2015

💔 Test failed - auto-mac-64-opt

@sfackler
Copy link
Member Author

@bors r=aturon

@bors
Copy link
Contributor

bors commented Aug 11, 2015

📌 Commit b51e009 has been approved by aturon

bors added a commit that referenced this pull request Aug 11, 2015
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.
@bors
Copy link
Contributor

bors commented Aug 11, 2015

⌛ Testing commit b51e009 with merge 50141d7...

@bors bors merged commit b51e009 into rust-lang:master Aug 11, 2015
@brson brson mentioned this pull request Aug 11, 2015
@alexcrichton alexcrichton removed the beta-nominated Nominated for backporting to the compiler in the beta channel. label Aug 12, 2015
@sfackler sfackler deleted the duration-stabilization branch November 26, 2016 05:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
beta-accepted Accepted for backporting to the compiler in the beta channel. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants