-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Use generic names for std RNG's #10053
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
Comments
There is some value in knowing the specific algorithm used, particularly if one wants to replay or independently generate specific seeded sequences of random numbers. I have done this from time to time for games. Another possibility could be typedefs to more generic names, which would allow replacing the default algorithms for people who don't care about the specific algorithm, but would still make removing specific ones difficult. |
An opinion from left field: This would prevent users from seeding the RNGs with fixed values and getting a fixed output stream across Rust versions. If I'm writing an automated test of some mathematical routine that uses random numbers, I may seed it so I will get the same results each time; if Rust changes the RNG under me, my tests will break. (For example, I may have some algorithm for sampling from a weird probability distribution. I could seed the RNG and compare Rust's output to a known-good algorithm, but then the output would change a few versions later.) |
We have |
Closing, I agree with @huonw, the current names are really all we need. |
improve `manual_is_ascii_check ` check Sorry, not familiar the api, i can only check the method name of expression `<expr-1>.contains(<expr-2>)` after read clippy book and hints from rust-lang#9933 . i dont know how to check 1. if <expr-1> is a specific range 2. <expr-2> is a character r? `@xFrednet` could you please provide some more hints? 😝️ --- changelog: Enhancement: [`manual_is_ascii_check`]: Now detects ranges with `.contains()` calls [rust-lang#10053](rust-lang/rust-clippy#10053) <!-- changelog_checked -->
We've continued to fiddle with our RNG's. It may not be prudent to expose the implementation details of them and instead just call them something like
FastRng
andCryptoRng
, to give us flexibility to change which algorithms are used in the future. On the other hand, an RNG like XorShift in particular has some peculiar properties that are implementation specifc, so it may be harder to replace. Opinions?The text was updated successfully, but these errors were encountered: