-
-
Notifications
You must be signed in to change notification settings - Fork 445
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Inherent rng methods #1492
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 |
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.md
entrySummary
Make
Rng
methods inherent methods on RNGs, and more usability tweaks.Motivation and details
This follows arguments made in #989 and #1488. Specifically,
Rng::gen_iter
torandom_iter
since it is the iterable version ofRng::random
Rng
methods onStdRng
,SmallRng
,ThreadRng
andStepRng
We removeChange removed from this PR.rand::random
, favouring usage ofrand::thread_rng().random
instead. This is not necessary but is more in-line with otherRng
methods.I did consider publicly exporting
impl_rng_methods_as_inherent
, but realised a problem:rand_chacha
cannot use this sincerand
depends 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_range
to justrange
? What aboutgen_bool
,gen_ratio
?Do we want to remove
rand::random
? If not, do we want to addrandom_iter
,gen_range
etc. as free functions? (rand::random
is hardly used insiderand
itself. This GitHub search has 33k code hits but it's hard to tell how many are genuine matches.)@oconnor663 gave motivation to rename
thread_rng
to 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.