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.

Sign up for GitHub

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

Jump to bottom

Tracking issue for extra Duration methods #46507

Closed
clarfonthey opened this issue Dec 5, 2017 · 12 comments
Closed

Tracking issue for extra Duration methods #46507

clarfonthey opened this issue Dec 5, 2017 · 12 comments
Labels
B-unstable Blocker: Implemented in the nightly compiler and unstable. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.

Comments

@clarfonthey
Copy link
Contributor

Right now, we have from_secs, from_millis, and from_micros, and also as_secs and subsec_nanos.

It makes sense to also add from_nanos, subsec_micros, and subsec_millis.
@clarfonthey clarfonthey mentioned this issue Dec 5, 2017
Merged
@TimNN TimNN added C-feature-request Category: A feature request, i.e: not implemented / a PR. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. labels Dec 5, 2017
bors added a commit that referenced this issue Dec 20, 2017
@bors
Auto merge of #46508 - clarcharr:duration_extras, r=sfackler
16212b9 
Add more Duration methods for consistency.

Follow-up to #46507.
@clarfonthey
Copy link
Contributor Author

@sfackler this should be marked as a tracking issue now

@sfackler sfackler added B-unstable Blocker: Implemented in the nightly compiler and unstable. and removed C-feature-request Category: A feature request, i.e: not implemented / a PR. labels Dec 23, 2017
@sfackler
Copy link
Member

Done!

@XAMPPRocky XAMPPRocky added C-enhancement Category: An issue proposing an enhancement or a PR with one. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. and removed C-enhancement Category: An issue proposing an enhancement or a PR with one. labels Feb 26, 2018
@SimonSapin
Copy link
Contributor

Looks good to me to stabilize.

@rfcbot fcp merge

@rfcbot
Copy link

rfcbot commented Mar 17, 2018 •
edited by aturon
Loading

Team member @SimonSapin has proposed to merge this. The next step is review by the rest of the tagged teams:

No concerns currently listed.

Once a majority of reviewers approve (and none object), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

@rfcbot rfcbot added the proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. label Mar 17, 2018
@kennytm kennytm mentioned this issue Mar 17, 2018
Closed
@rfcbot
Copy link

rfcbot commented Mar 19, 2018

🔔 This is now entering its final comment period, as per the review above. 🔔

@rfcbot rfcbot added final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. and removed proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. labels Mar 19, 2018
@axos88
Copy link

axos88 commented Mar 23, 2018

I feel like subsec_* methods have limited use.
I find myself interested in converting the whole duration value to e.g. millis most of the time rather than interested in only the fractional part.
I would propose to add as_millis, as_micros, as_nanos, etc. conforming with the from_* methods.

@birkenfeld
Copy link
Contributor

And similarly, for formatting/display purposes, as_floating_secs etc would be helpful.

@rfcbot
Copy link

rfcbot commented Mar 29, 2018

The final comment period is now complete.

@clarfonthey
Copy link
Contributor Author

@birkenfeld personally I'd rather have subsec_float which returns a number between 0 and 1 for maximal precision, and then you can do subsec_float + sec as f64 if you want the total number. but that's more picky imho and I doubt many people want that use case

@clarfonthey clarfonthey changed the title Duration should have consistent methods for all units Tracking issue for extra Duration methods Apr 15, 2018
@tinaun tinaun mentioned this issue Apr 17, 2018
Merged
bors added a commit that referenced this issue Apr 18, 2018
@bors
Auto merge of #50017 - tinaun:stabilize-all-the-things, r=sfackler
ac3c228 
stabilize a bunch of minor api additions

besides `ptr::NonNull::cast` (which is 4 days away from end of FCP) all of these have been finished with FCP for a few weeks now with minimal issues raised

* Closes #41020
* Closes #42818
* Closes #44030
* Closes #44400
* Closes #46507
* Closes #47653
* Closes #46344

the following functions will be stabilized in 1.27:
* `[T]::rsplit`
* `[T]::rsplit_mut`
* `[T]::swap_with_slice`
* `ptr::swap_nonoverlapping`
* `NonNull::cast`
* `Duration::from_micros`
* `Duration::from_nanos`
* `Duration::subsec_millis`
* `Duration::subsec_micros`
* `HashMap::remove_entry`
@KamilaBorowska
Copy link
Contributor

KamilaBorowska commented May 10, 2018 •
edited
Loading

I know it's late (but it isn't in stable yet), but I wonder if from_nanos shouldn't use u128 instead of u64. Although I suppose it matches rest of methods, so whatever.

@icefoxen
Copy link
Contributor

@xfix I'm not involved in this decision but it appears that 2^64 seconds is about 42x the age of the universe. So, u64 is Probably Enough For Anyone. :-P

@retep998
Copy link
Member

retep998 commented May 14, 2018 •
edited
Loading

Yeah but from_nanos is 2^64 nanoseconds, not seconds, which is only about 585 years. That's really short. A mostly forward compatible change would be to make it take a generic type parameter of either u128 or u64 but that could have subtle inference changes. However this stabilization is for Rust 1.27 which hasn't landed yet so we still have a chance to revert stabilization.

@retep998 retep998 mentioned this issue May 27, 2018
Closed
@ocisly ocisly mentioned this issue Apr 21, 2019
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
B-unstable Blocker: Implemented in the nightly compiler and unstable. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests