Add more Duration methods for consistency.

[clarfonthey]

Follow-up to #46507.

[rust-highfive]

r? @KodrAus

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

[sfackler]

I'm on board with these methods!

@rfcbot fcp merge

[rfcbot]

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

• @BurntSushi
• @Kimundi
• @alexcrichton
• @aturon
• @dtolnay
• @sfackler

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]

Tidy's failing

[Mark-Simulacrum]

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

[sfackler]

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

[Mark-Simulacrum]

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

[clarfonthey]

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]

I personally would rather that from_nanos take u128.

[kennytm]

@retep998 A u128 nanoseconds will overflow Duration which only supports u64 seconds (2¹²⁸ / 10⁹ = 3.4 × 10²⁹; 2⁶⁴ = 1.8 × 10¹⁹). 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.

[clarfonthey]

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

[clarfonthey]

also @sfackler the build is passing now

[retep998]

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

[sfackler]

@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]

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

[clarfonthey]

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]

Ping @aturon for ticky boxes!

[rfcbot]

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

[alexcrichton]

@bors: r=sfackler

[bors]

📌 Commit 2be7a31 has been approved by sfackler

[bors]

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

[bors]

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

[retep998]

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