Sort of prior art, albeit in progress and unreleased: I'm rewriting the time crate, and included this exact method. It is slightly different in that the implementation allows for both positive and negative durations, and there are corresponding methods.

I fully support, though! Even though I don't think an RFC is necessary for something like this :)

A couple of notes:

• I would not in general expect == time::ZERO to generate more code than the is_zero method, especially if == gets inlined. I do think that .is_zero() seems more readable, though, and I still think we should have an .is_zero() method, but I don't think we need it for performance reasons specifically.

• Another alternative: we could have a constant function Duration::zero() that generates a zero duration. Worth mentioning as an alternative, I think.

👍 On adding is_zero. Seems like a small and useful addition to me.

@joshtriplett mentioned Duration::zero() as alternative. I would like to propose it as a potential addition. I.e. let's just add Duration::is_zero and Duration::zero.

And as mentioned in the issue you opened, it would have probably been fine to directly create a PR on the main repo. It's a really small change.

@LukasKalbertodt

Thanks. I've updated the file.

I will create new PR if this RFC would be changed to "final comment period" state (like in guideline). It would prevent a lot of changes from time to time, while this RFC is being updated.

This really doesn't have to go through the full RFC process, a PR on rust-lang/rust is just fine. Closing in favor of that.

@jonas-schievink #2809 can be closed as well, then, I believe.