Tracking Issue for `Duration::{zero, is_zero}` (`#![feature(duration_zero)]`)

[LukasKalbertodt]

This is a tracking issue for Duration::{ZERO, is_zero} (#![feature(duration_zero)]). Proposed in RFC 2814 which got closed just because such a small change does not require an RFC. Proposed again and implemented in #72790.

impl Duration {
    pub const ZERO: Duration;
    pub const fn is_zero(&self) -> bool;
}

Steps

• Implement (core/time: Add Duration methods for zero #72790)
• FCP
• Stabilization PR (Stabilize duration_zero. #84084)

Unresolved questions:

• Also add an associated constant ZERO? yes. done
• Should the associated constant be preferred over the zero function? yes, zero() is removed.

[tesuji]

You may want to edit the title of this issue.

[LukasKalbertodt]

@lzutao Oh gosh, I'm sorry. First time using the GitHub template option 😅

[MightyPork]

Are there plans for stabilization?

I had these two traits in my code for over a year, and they now show the "unstable_name_collisions" lint every build, everywhere they're used - #[allow(unstable_name_collisions)] does not work well with a workspace, I have to put it in all modules or rename the functions :/

/// Extensions for `Duration`
pub trait DurationExt : Copy {
    /// Returns true if self is equivalent to zero
    fn is_zero(self) -> bool;

    /// Get a zero duration
    fn zero() -> Duration {
        Duration::new(0, 0)
    }
}

impl DurationExt for Duration {
    #[inline]
    fn is_zero(self) -> bool {
        self.as_secs() == 0 && self.subsec_nanos() == 0
    }
}

[jonhoo]

My guess is that these can probably be stabilized as-is?

[LukasKalbertodt]

As the top comments says, the only open question is basically whether we want the associated const ZERO instead of the two methods.

// Do we want this?
let d = Duration::zero();
if d.is_zero() { ... }

// Or rather this?
let d = Duration::ZERO;
if d == Duration::ZERO { ... }

There are certainly some uses of associated consts in std already:

• Ip4Addr::{LOCALHOST, BROADCAST, UNSPECIFIED}. Ip4Addr also has plenty of is_* methods, including is_broadcast. It does not have localhost, .. constructors functions.
• Integers and floats have associated consts and no constructor functions.

I think both of those two solutions (or any mix of those) would be fine. I don't think anyone would consider either of those a "bad API". So if you think that either one of those should be stabilized, go ahead and either open a PR that adds the const ZERO or a PR that stabilizes the existing methods. In either case, provide some reasoning why the API you're suggesting is good/better.

[MightyPork]

I was thinking about the pros and cons, and I'm really divided, though leaning slightly towards ZERO

Duration::zero()

• Intuitive (demonstrated by my independently invented trait with the same methods)
• Might be more obvious to beginners who don't know that Duration is Copy - it looks like a constructor
• Can be used in places that accept Fn() -> Duration - I'm not sure how useful that really is
• Optimized to a constant = no overhead

Duration::ZERO

• Cheap and straightforward, it is a constant
• Name clearly indicates it's a constant
• A bit shorter
• Has a precedent in Ip4Addr

Regardless, is_zero() is a useful addition - although you can use d == Duration::ZERO, calling a method is much more succinct and makes for cleaner code

[Rua]

My preference is for the constant. Places that need a function can easily be given || Duration::ZERO, which doesn't seem like much of a bother.

[workingjubilee]

As of #78216, Nightly Rust moves to the constant for a variety of reasons stated here, in addition to the fact that a const does not require a const evaluation context in order to be used in places where consts but not dynamic values are accepted... this matters a lot for match contexts and the many sugared versions of match.