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
Add a module with helper functions #989
Comments
Is this primarily because We should be careful about adding more convenience functions (complicating the API for ease-of-use), and also realise that we can't be all-things-to-everyone (some people really care about minimising dependencies/size for whatever reason; |
There are a lot of crates like this, implementing some subset of Rand's functionality. There does not seem to be any convergence on a "quick and dirty" randomness crate, with every author creating their own variant. I don't see what we can do about this code duplication. How popular are these crates? I'm not sure that there is a risk of an ecosystem split. Looking at fastrand, it seems the main API simplification is getting rid of |
Don't forget that helper functions not only shorter (due to the implicitness of Since those functions are trivial and will be kept in a separate module, I don't think they will be perceived as an API complication and additional maintenance burden will be minuscule. Judging by a cursory look at these search results, I would say that the proposed helper functions will cover more than half of explciit
I wouldn't call it a convenience wrapper. It's an extension trait which implements additional functionality. |
Not really, it only wraps |
There is also good reason to keep
The main drawback IMO is that in the docs there will be a long-ish section at the bottom of all these functions. But I wouldn't want to remove let mut rng = thread_rng();
let dist = Uniform::from(1..11);
let sample = dist.sample(&mut rng); Conclusion: I see only very minor advantages and drawbacks — so either option sounds acceptable. |
So to resolve this, we would have to implement the following? Via
New methods for
|
My opinion is that we should not attempt to "resolve" this issue without more feedback on what users want and why. Of the above, I don't see anything wrong with adding Adding methods like One thing we can't compete with Ironically the selling point of |
I was hoping more people might pitch in with what they would / would not like to see. So, here's my opinion (again):
Regarding (1): The Regarding (3): Should we impl |
I've always felt that Rust needs a crate for "simple" random number generation. It's definitely hard to draw the line for exactly what to include in such a crate though. To answer the question in #989 (comment), I think the goal of such a crate would primarily be "easy to learn" rather than "few characters to type". To accomplish this I would heavily bias towards having few functions in the API. My proposal would be to include just
And that these functions would use a cryptographically-secure algorithm and optimized for precision to the extent rand is right now (i.e. use exclusion zones for integer generation, but just 53 bits of precision for floats) Most other commonly needed things can be easily and intuitively built on top of those functions. Possibly more functions than the above should have convenience APIs. But it's always easy to add more over time. However I don't think the Honestly I think But I think that the |
Interesting direction: adding |
One of the major
rand
critiques, which I've recently seen, argues that it makes hard to write "quick and dirty" code. This motivates creation of crates likefastrand
, which could lead to an unfortunate ecosystem split and overall code duplication.We already have the
random
helper function and I think it could be worth to add other helper functions as well. To make docs less cluttered we probably should keep them in a separate top-level module (something likehelpers
?). With the potential migration to ChaCha8/12, those functions can be simple wrappers aroundthread_rng
and be fast enough for all, but most demanding use-cases. One of side-effects of using helpers is that trait imports are no longer needed for simple use-cases, so it could be seen as a work-around until something like rust-lang/rfcs#2375 gets added to the language.A preliminary list of helper functions:
random
(Rng::gen
)gen_range
(ideally should be consistent withgen_range
, see gen_range doesn't take a Range #744)fill
gen_bool
/gen_ratio
choose
/choose_mut
shuffle
We could tweak naming a bit to make it a bit more natural.
cc @stjepang
The text was updated successfully, but these errors were encountered: