Add functions to generate random u32 and u64 values
#544
Conversation
|
@newpavlov maybe though not really important for |
|
@dhardy |
There was a problem hiding this comment.
So IIUC the purpose of the extra API is to:
- Avoid an allocation when using WASI P2. I'd be tempted just to test whether
dest.len() <= 8(or some larger threshold) and useget_random_u64then... except you always use that anyway. (Is this approach sensible for large buffers anyway?) - Minor optimisations for RDRAND/RNDR
To me, this doesn't seem to be sufficient reason to introduce the extra API surface.
|
The main motivation is user convenience, since the main use case of this crate is seed generation. The |
I always saw this crate as a low level implementation crate, not something which would be used directly by many users. getrandom does now have 1093 published dependent crates to rand's 16269, so maybe I'm partly wrong. |
These functions can be helpful for seed generation and implementation of
OsRng. Additionally, some backends (Hermit, RDRAND, RNDR, WASI p2) can directly generate randomu32/u64values. Relying on the byte API may be less efficient in these cases.Using
u32andu64as function names may seem problematic, but based on thefastrandexperience, it works well in practice, provided that users reference them asgetrandom::u32/u64without importing them directly.