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

Impl Arbitrary for Naive{Date,Time,DateTime} #848

Closed

Conversation

greyblake
Copy link
Contributor

@greyblake greyblake commented Oct 17, 2022

I'd love to see #559 moving forward, but looks like @asayers has no time to address the code review right now.
Since I am very interested in the support of Arbitrary I've decided to cherry pick his commit and address the code review.

What is in this PR:

  • Implementation of Arbitrary behind feature flag for NaiveDate, NaiveTime, NaiveDateTime.
  • Unit tests for NaiveDate and NaiveTime (no unit test for NaiveDateTime, since it's implementation of Arbitrary is derived)
  • The implementation and tests are placed into arbitrary modules (in the same fashion like it's done with serde)

Considerations

Despite

let ord = u.int_in_range(1..=366)?;

does not make large difference when constructing NaiveDate as @djc mentioned, I've decided to use YearFlags, so the both implementations for NaiveDate and NaiveTime are implemented in similar infallible fashion.

@djc
Copy link
Contributor

djc commented Oct 17, 2022

What is the value of adding unit tests here? The code seems relatively simple.

Copy link
Contributor

@djc djc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for picking this up!

Would probably make sense to target the 0.4.x branch for this?

fn arbitrary(u: &mut Unstructured) -> arbitrary::Result<NaiveTime> {
let secs = u.int_in_range(0..=86_399)?;
let nano = u.int_in_range(0..=1_999_999_999)?;
let time = NaiveTime::from_num_seconds_from_midnight_opt(secs, nano)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's the rationale for panicking here vs returning an error?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My primary motivation was this comment #559 (comment), which you thumbed up.
I am OK with both approaches, both have their pros and cons. With this one (unwrap/expect) we'll detect the problem faster if somethings gets broken. (Arbitrary is implement that way, that if something returns an error, it retries to generate data until it succeeds).

@greyblake
Copy link
Contributor Author

greyblake commented Oct 17, 2022

@djc

What is the value of adding unit tests here? The code seems relatively simple.

I have this habit of adding them to almost every change I do. If you think they are not necessary I can drop them. Please let me know.

Would probably make sense to target the 0.4.x branch for this?

I am fine. Should I open a similar PR to 0.4.x branch (keep 2 PRs) or should I close this one and open a PR into 0.4.x (only one PR). Sorry, I don't know what's the difference between 0.4 and 0.5.

P.S. I would be happy to implement all other stuff for the full support of Arbitrary and see it's released ASAP (in this regard 0.4.x is even more attractive for me at the moment).

@djc
Copy link
Contributor

djc commented Oct 17, 2022

Just retarget this PR to 0.4.x, changes that get merged there eventually are merged into main.

@greyblake greyblake mentioned this pull request Oct 17, 2022
@greyblake
Copy link
Contributor Author

@djc Thanks for the feedback. So I am closing this one in favor of #849

@greyblake greyblake closed this Oct 17, 2022
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

3 participants