Description
Roughly, rand could be modularised as follows:
component | dependencies |
---|---|
rand_core |
|
PRNG crates | core |
rand_os |
core + std |
JitterRng |
core + std |
EntropyRng |
core + os + jitter + std |
ThreadRng |
core + os + jitter + entropy + std + hc |
seq |
core |
distributions |
core |
Rng |
core + seq + distributions |
Roughly 30% of the current code comes under non-linear distributions, which is its own story (#290). For the rest I don't think there's sufficient utility for more crates.
I regret accepting #643 as-is; it "promises" to support all std
platforms yet fails on WASM with a compile error (#674, #678) and on any unsupported platforms. The reasons that is an issue are convoluted (probably involving users depending on rand
with default features yet not needing them all), but the conclusion of #678 is that Rand should always build for wasm32-unknown-unknown
, failing if necessary at run-time.
We used to use run-time failure within EntropyRng
but disable OsRng
at compile time where unneeded. Practical solutions are:
- Restore the old behavior:
rand_os
must compile but without theOsRng
struct on unsupported platforms.EntropyRng
is currently available on all platforms but with run-time failure when no source is available, however it requires a complexcfg
pattern in order to disable the missingOsRng
dependency when not available; it would therefore make sense to have this in the same crate. - Enable
OsRng
on WASM, and use run-time failure on missing implementation. - Enable
OsRng
on all platforms, and use run-time failure on missing implementation.
I think the cleanest solution would be (1), but @tarcieri @naftulikay I understand there would be resistance to moving JitterRng
into rand_os
. Is this really justified? I guess in part this depends on whether the RFC proposed in #648 gets accepted, though this will be a while coming.
Otherwise we can do (2) or (3); the difference is that (2) would cause build failures on any platform where Rand is used with std
/default features but OsRng
is unavailable. I'm not sure whether this is a good idea?
I suppose (2) is most sensible now.