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.

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

Adding is_zero() to core::time::Duration #2814

Closed
wants to merge 4 commits into from
Closed

Adding is_zero() to core::time::Duration #2814

wants to merge 4 commits into from

Conversation

ghost
Copy link

@ghost ghost commented Nov 12, 2019

This PR is for adding new function is_zero() to core::time::Duration.

Related issue: #2809

@ghost ghost marked this pull request as ready for review November 12, 2019 03:48
@jhpratt
Copy link
Member

jhpratt commented Nov 12, 2019

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 :)

@joshtriplett
Copy link
Member

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.

@LukasKalbertodt
Copy link
Member

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

- Added `zero()` as one alternative and future possibility.
- Removed some drawbacks of `ZERO` alternative.
@ghost
Copy link
Author

ghost commented Nov 14, 2019

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

@jonas-schievink
Copy link
Contributor

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.

@jhpratt
Copy link
Member

jhpratt commented Dec 5, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants