-
-
Notifications
You must be signed in to change notification settings - Fork 436
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
Consider hiding StdRng behind a feature flag #938
Comments
I'm not keen on this. @vks @newpavlov thoughts? |
Yeah, it should definitely be an |
I am in support of adding an enabled-by-default feature for |
Are you using the emscripten target? IIRC, we only use `rand_hc` because
emscripten does not support `u128`.
I think it might make sense to put `StdRng`, `thread_rng` and possibly the
reseeding machinery behind a feature flag (enabled by default). There is a
demand for lightweight RNG libraries, as evidenced by the various Rand
alternatives without CSPRNGs.
As mentioned before, this would of course be a breaking change.
|
No, but it still ends up in Cargo.lock, because Cargo.lock is created for a union of all targerts. |
Fair enough, I guess we can introduce an on-by-default feature flag. Next question is, one or two? We have no guarantee that |
Hi!
So I've noticed that even if I use rand with what I think is the minimal profile,
I still get both chacha (with its deps) and hc.
However, I am specifically interested in a single fast non-cryptographic manually seeded rng (and small Cargo.lock :) ).
I've tried to apply the following patch to
rand
, and it seems like it did the trick?The text was updated successfully, but these errors were encountered: