-
-
Notifications
You must be signed in to change notification settings - Fork 484
Inherent rng methods #1492
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
Inherent rng methods #1492
Conversation
|
I was intending to leave these changes until after Some more thoughts:
|
2a5de77 to
7c72ebd
Compare
|
This PR no longer removes the |
newpavlov
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Personally, I do not like duplication of trait methods as inherent. I think it obscures the code and make it less consistent across crates.
|
I want to agree, especially since these inherent impls will not work for any RNG outside of |
This extracts the non-inherent-methods stuff from #1492.
a7ddabf to
9af9444
Compare
This extracts the non-inherent-methods stuff from rust-random#1492.
This extracts the non-inherent-methods stuff from rust-random#1492.
CHANGELOG.mdentrySummary
Make
Rngmethods inherent methods on RNGs, and more usability tweaks.Motivation and details
This follows arguments made in #989 and #1488. Specifically,
Rng::gen_itertorandom_itersince it is the iterable version ofRng::randomRngmethods onStdRng,SmallRng,ThreadRngandStepRngWe removeChange removed from this PR.rand::random, favouring usage ofrand::thread_rng().randominstead. This is not necessary but is more in-line with otherRngmethods.I did consider publicly exporting
impl_rng_methods_as_inherent, but realised a problem:rand_chachacannot use this sinceranddepends onrand_chacha(and the macro cannot be moved torand_core); some other RNG crates could use this but should not depend onrand.Incomplete / questions
Do we want to rename
gen_rangeto justrange? What aboutgen_bool,gen_ratio?Do we want to remove
rand::random? If not, do we want to addrandom_iter,gen_rangeetc. as free functions? (rand::randomis hardly used insideranditself. This GitHub search has 33k code hits but it's hard to tell how many are genuine matches.)@oconnor663 gave motivation to rename
thread_rngto justrng:We could do this. If this were a clean design then probably we should: it's an implementation detail that we use a thread-local generator and not, say, a mutex over a single (static) generator. But it's also rather widely used: approx 150 mentions in this repo and 176k code hits via GitHub search.