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

Add more Duration methods for consistency. #46508

Merged
merged 1 commit into from Dec 20, 2017

Conversation

Projects
None yet
10 participants
@clarcharr
Contributor

clarcharr commented Dec 5, 2017

Follow-up to #46507.

@rust-highfive

This comment has been minimized.

Show comment
Hide comment
@rust-highfive

rust-highfive Dec 5, 2017

Collaborator

r? @KodrAus

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

Collaborator

rust-highfive commented Dec 5, 2017

r? @KodrAus

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

@sfackler sfackler added the T-libs label Dec 5, 2017

@sfackler

This comment has been minimized.

Show comment
Hide comment
@sfackler

sfackler Dec 5, 2017

Member

I'm on board with these methods!

@rfcbot fcp merge

Member

sfackler commented Dec 5, 2017

I'm on board with these methods!

@rfcbot fcp merge

@rfcbot

This comment has been minimized.

Show comment
Hide comment
@rfcbot

rfcbot Dec 5, 2017

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

No concerns currently listed.

Once these reviewers reach consensus, 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 commented Dec 5, 2017

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

No concerns currently listed.

Once these reviewers reach consensus, 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.

@sfackler

This comment has been minimized.

Show comment
Hide comment
@sfackler

sfackler Dec 5, 2017

Member

Tidy's failing

Member

sfackler commented Dec 5, 2017

Tidy's failing

/// ```
#[unstable(feature = "duration_extras", issue = "46507")]
#[inline]
pub fn from_nanos(nanos: u64) -> Duration {

This comment has been minimized.

@Mark-Simulacrum

Mark-Simulacrum Dec 5, 2017

Member

This feels like it should be from_nanosecs or something like that by the convention in other methods.

@Mark-Simulacrum

Mark-Simulacrum Dec 5, 2017

Member

This feels like it should be from_nanosecs or something like that by the convention in other methods.

This comment has been minimized.

@sfackler

sfackler Dec 5, 2017

Member

The existing constructors are new, from_secs, from_millis, and from_micros, so it seems like from_nanos would match conventions?

@sfackler

sfackler Dec 5, 2017

Member

The existing constructors are new, from_secs, from_millis, and from_micros, so it seems like from_nanos would match conventions?

This comment has been minimized.

@Mark-Simulacrum

Mark-Simulacrum Dec 5, 2017

Member

I guess we've been somewhat inconsistent with abbreviating seconds already, so this seems fine.

@Mark-Simulacrum

Mark-Simulacrum Dec 5, 2017

Member

I guess we've been somewhat inconsistent with abbreviating seconds already, so this seems fine.

This comment has been minimized.

@clarcharr

clarcharr Dec 5, 2017

Contributor

I personally like the use of the pluralised prefices, considering how simply using ns, us, and ms would be very easy to make typos. I don't personally like using sec as an abbreviation for second considering how sec is secant and s is second, but that's just because I'm a maths person and I appreciate clarity in equations. We shouldn't really change the naming scheme now that this has been stabilised for a long time.

@clarcharr

clarcharr Dec 5, 2017

Contributor

I personally like the use of the pluralised prefices, considering how simply using ns, us, and ms would be very easy to make typos. I don't personally like using sec as an abbreviation for second considering how sec is secant and s is second, but that's just because I'm a maths person and I appreciate clarity in equations. We shouldn't really change the naming scheme now that this has been stabilised for a long time.

@retep998

This comment has been minimized.

Show comment
Hide comment
@retep998

retep998 Dec 5, 2017

Member

I personally would rather that from_nanos take u128.

Member

retep998 commented Dec 5, 2017

I personally would rather that from_nanos take u128.

@kennytm

This comment has been minimized.

Show comment
Hide comment
@kennytm

kennytm Dec 5, 2017

Member

@retep998 A u128 nanoseconds will overflow Duration which only supports u64 seconds (2128 / 109 = 3.4 × 1029; 264 = 1.8 × 1019). If it accepts a u128, either the method needs to return Result<Duration, _> or it needs to panic on overflow, or we need to change the representation of Duration to use u128 nanoseconds internally.

Member

kennytm commented Dec 5, 2017

@retep998 A u128 nanoseconds will overflow Duration which only supports u64 seconds (2128 / 109 = 3.4 × 1029; 264 = 1.8 × 1019). If it accepts a u128, either the method needs to return Result<Duration, _> or it needs to panic on overflow, or we need to change the representation of Duration to use u128 nanoseconds internally.

@clarcharr

This comment has been minimized.

Show comment
Hide comment
@clarcharr

clarcharr Dec 5, 2017

Contributor

@retep998 u64 of nanoseconds covers approximately 584 942 years. do we really need more precision?

Contributor

clarcharr commented Dec 5, 2017

@retep998 u64 of nanoseconds covers approximately 584 942 years. do we really need more precision?

@clarcharr

This comment has been minimized.

Show comment
Hide comment
@clarcharr

clarcharr Dec 5, 2017

Contributor

also @sfackler the build is passing now

Contributor

clarcharr commented Dec 5, 2017

also @sfackler the build is passing now

@retep998

This comment has been minimized.

Show comment
Hide comment
@retep998

retep998 Dec 5, 2017

Member

@clarcharr You can ask that question to whoever designed Duration as u64 seconds and u32 nanoseconds instead of simply u64 nanoseconds.

Member

retep998 commented Dec 5, 2017

@clarcharr You can ask that question to whoever designed Duration as u64 seconds and u32 nanoseconds instead of simply u64 nanoseconds.

@sfackler

This comment has been minimized.

Show comment
Hide comment
@sfackler

sfackler Dec 5, 2017

Member

@retep998 I don't see why that's a problem. If you can't initialize a Duration via a number of nanoseconds, you can do it via new. This is already the case for from_millis.

Member

sfackler commented Dec 5, 2017

@retep998 I don't see why that's a problem. If you can't initialize a Duration via a number of nanoseconds, you can do it via new. This is already the case for from_millis.

@retep998

This comment has been minimized.

Show comment
Hide comment
@retep998

retep998 Dec 5, 2017

Member

Ah right, from_millis has the same tradeoff. In that case I'm fine with from_nanos as written.

Member

retep998 commented Dec 5, 2017

Ah right, from_millis has the same tradeoff. In that case I'm fine with from_nanos as written.

@clarcharr

This comment has been minimized.

Show comment
Hide comment
@clarcharr

clarcharr Dec 7, 2017

Contributor

Does this need the final check from @aturon considering how all of these methods are already feature-gated? Was going to make a PR for #46520 but I want to merge this first.

Contributor

clarcharr commented Dec 7, 2017

Does this need the final check from @aturon considering how all of these methods are already feature-gated? Was going to make a PR for #46520 but I want to merge this first.

@kennytm

This comment has been minimized.

Show comment
Hide comment
@kennytm
Member

kennytm commented Dec 14, 2017

Ping @aturon for ticky boxes!

@rfcbot

This comment has been minimized.

Show comment
Hide comment
@rfcbot

rfcbot Dec 19, 2017

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

rfcbot commented Dec 19, 2017

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

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Dec 19, 2017

Member

@bors: r=sfackler

Member

alexcrichton commented Dec 19, 2017

@bors: r=sfackler

@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Dec 19, 2017

Contributor

📌 Commit 2be7a31 has been approved by sfackler

Contributor

bors commented Dec 19, 2017

📌 Commit 2be7a31 has been approved by sfackler

@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Dec 20, 2017

Contributor

⌛️ Testing commit 2be7a31 with merge 16212b9...

Contributor

bors commented Dec 20, 2017

⌛️ Testing commit 2be7a31 with merge 16212b9...

bors added a commit that referenced this pull request Dec 20, 2017

Auto merge of #46508 - clarcharr:duration_extras, r=sfackler
Add more Duration methods for consistency.

Follow-up to #46507.
@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Dec 20, 2017

Contributor

☀️ Test successful - status-appveyor, status-travis
Approved by: sfackler
Pushing 16212b9 to master...

Contributor

bors commented Dec 20, 2017

☀️ Test successful - status-appveyor, status-travis
Approved by: sfackler
Pushing 16212b9 to master...

@bors bors merged commit 2be7a31 into rust-lang:master Dec 20, 2017

2 checks passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
homu Test successful
Details

bors added a commit that referenced this pull request Jan 31, 2018

Auto merge of #46666 - clarcharr:duration_core, r=alexcrichton
Move Duration to libcore

Fixes #46520; should be merged after #46508.

@clarcharr clarcharr deleted the clarcharr:duration_extras branch Apr 15, 2018

@retep998

This comment has been minimized.

Show comment
Hide comment
@retep998

retep998 May 14, 2018

Member

@retep998 u64 of nanoseconds covers approximately 584 942 years. do we really need more precision?

@clarcharr Did you mean microseconds, because u64 of nanoseconds only goes to 585 years which is actually quite short.

Member

retep998 commented May 14, 2018

@retep998 u64 of nanoseconds covers approximately 584 942 years. do we really need more precision?

@clarcharr Did you mean microseconds, because u64 of nanoseconds only goes to 585 years which is actually quite short.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment