-
Notifications
You must be signed in to change notification settings - Fork 148
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
Quickcheck Arbitrary support? #241
Comments
Sure, that sounds good. It's a niche use though, so please make it an
opt-in feature, not default.
|
That was the plan. :) One question I had about some semantics, when say generating some arbitrary BigUint, what should the range be? Taking a |
I guess that depends how it will be used. A bigint that long is not inherently unreasonable, but could certainly be slow for some scenarios. I'll leave that to your discretion for now. :-) |
What about atoms in the observable universe? 4*10^81? |
Is it kosher to put arbitrary limits on I would just leave it with whatever We could invent scenarios where almost any bigint would hurt, like some exponential algorithm. So we have to be a bit pragmatic according to how it will actually be used. |
Suppose you're right. :) It's hardly arbitrary if we limit it. |
@Hoverbear Are you still working on this? If not, I'd like to. |
@remexre It fell of my plate! If you'd like to take it over please feel free. |
I'd love to `impl<T: Into<String>> From<T> for Value` and probably also `impl<T: Iterator<Item=I>, I: Into<Value> From<T> for Value`. Maybe with specialization? Fixes rust-num#241
Closing in favor of the new separate issues: |
Would there be interest in supporting (perhaps via a feature) the Quickcheck Arbitrary trait?
An example:
Reasoning:
quickcheck! {}
based tests.Arbitrary
onBigUint
, for example, since it it part of a different crate.I would be interested in working on this PR but I want to make sure it would be welcome.
The text was updated successfully, but these errors were encountered: