Add functions to generate random u32 and u64 values

[newpavlov]

These functions can be helpful for seed generation and implementation of OsRng. Additionally, some backends (Hermit, RDRAND, RNDR, WASI p2) can directly generate random u32/u64 values. Relying on the byte API may be less efficient in these cases.

Using u32 and u64 as function names may seem problematic, but based on the fastrand experience, it works well in practice, provided that users reference them as getrandom::u32/u64 without importing them directly.

[newpavlov]

cc @dhardy@briansmith

[dhardy]

@newpavlov maybe though not really important for rand_core (we can already convert from bits). In any case, I won't depend on this until a new release is out so don't expect it to see use in rand v0.9.0.

[newpavlov]

@dhardy
My plan is to release getrandom v0.3 before before rand v0.9. You will not be able to silently migrate from v0.2 to v0.3 even with rust-random/rand#1537 because of the changes around optional backend handling.

[dhardy]

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 use get_random_u64 then... 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.

[newpavlov]

The main motivation is user convenience, since the main use case of this crate is seed generation. The u32/u64 generation support by some platforms is just an additional argument for why it should be done in this crate.

[dhardy]

The main motivation is user convenience, since the main use case of this crate is seed generation.

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.

[newpavlov]

These functions can be helpful for seed generation and implementation of OsRng. Additionally, some backends (Hermit, RDRAND, RNDR, WASI p2) can directly generate random u32/u64 values. Relying on the byte API may be less efficient in these cases.

Using u32 and u64 as function names may seem problematic, but based on the fastrand experience, it works well in practice, provided that users reference them as getrandom::u32/u64 without importing them directly.

[newpavlov]

cc @dhardy@briansmith

[dhardy]

@newpavlov maybe though not really important for rand_core (we can already convert from bits). In any case, I won't depend on this until a new release is out so don't expect it to see use in rand v0.9.0.

[newpavlov]

@dhardy
My plan is to release getrandom v0.3 before before rand v0.9. You will not be able to silently migrate from v0.2 to v0.3 even with rust-random/rand#1537 because of the changes around optional backend handling.

[dhardy]

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 use get_random_u64 then... 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.

[newpavlov]

The main motivation is user convenience, since the main use case of this crate is seed generation. The u32/u64 generation support by some platforms is just an additional argument for why it should be done in this crate.

[dhardy]

The main motivation is user convenience, since the main use case of this crate is seed generation.

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.

[newpavlov]

These functions can be helpful for seed generation and implementation of OsRng. Additionally, some backends (Hermit, RDRAND, RNDR, WASI p2) can directly generate random u32/u64 values. Relying on the byte API may be less efficient in these cases.

Using u32 and u64 as function names may seem problematic, but based on the fastrand experience, it works well in practice, provided that users reference them as getrandom::u32/u64 without importing them directly.

[newpavlov]

cc @dhardy@briansmith

[dhardy]

@newpavlov maybe though not really important for rand_core (we can already convert from bits). In any case, I won't depend on this until a new release is out so don't expect it to see use in rand v0.9.0.

[newpavlov]

@dhardy
My plan is to release getrandom v0.3 before before rand v0.9. You will not be able to silently migrate from v0.2 to v0.3 even with rust-random/rand#1537 because of the changes around optional backend handling.

[dhardy]

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 use get_random_u64 then... 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.

[newpavlov]

The main motivation is user convenience, since the main use case of this crate is seed generation. The u32/u64 generation support by some platforms is just an additional argument for why it should be done in this crate.

[dhardy]

The main motivation is user convenience, since the main use case of this crate is seed generation.

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.

[newpavlov]

These functions can be helpful for seed generation and implementation of OsRng. Additionally, some backends (Hermit, RDRAND, RNDR, WASI p2) can directly generate random u32/u64 values. Relying on the byte API may be less efficient in these cases.

Using u32 and u64 as function names may seem problematic, but based on the fastrand experience, it works well in practice, provided that users reference them as getrandom::u32/u64 without importing them directly.

[newpavlov]

cc @dhardy@briansmith

[dhardy]

@newpavlov maybe though not really important for rand_core (we can already convert from bits). In any case, I won't depend on this until a new release is out so don't expect it to see use in rand v0.9.0.

[newpavlov]

@dhardy
My plan is to release getrandom v0.3 before before rand v0.9. You will not be able to silently migrate from v0.2 to v0.3 even with rust-random/rand#1537 because of the changes around optional backend handling.

[dhardy]

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 use get_random_u64 then... 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.

[newpavlov]

The main motivation is user convenience, since the main use case of this crate is seed generation. The u32/u64 generation support by some platforms is just an additional argument for why it should be done in this crate.

[dhardy]

The main motivation is user convenience, since the main use case of this crate is seed generation.

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.

[newpavlov]

These functions can be helpful for seed generation and implementation of OsRng. Additionally, some backends (Hermit, RDRAND, RNDR, WASI p2) can directly generate random u32/u64 values. Relying on the byte API may be less efficient in these cases.

Using u32 and u64 as function names may seem problematic, but based on the fastrand experience, it works well in practice, provided that users reference them as getrandom::u32/u64 without importing them directly.

[newpavlov]

cc @dhardy@briansmith

[dhardy]

@newpavlov maybe though not really important for rand_core (we can already convert from bits). In any case, I won't depend on this until a new release is out so don't expect it to see use in rand v0.9.0.

[newpavlov]

@dhardy
My plan is to release getrandom v0.3 before before rand v0.9. You will not be able to silently migrate from v0.2 to v0.3 even with rust-random/rand#1537 because of the changes around optional backend handling.

[dhardy]

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 use get_random_u64 then... 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.

[newpavlov]

The main motivation is user convenience, since the main use case of this crate is seed generation. The u32/u64 generation support by some platforms is just an additional argument for why it should be done in this crate.

[dhardy]

The main motivation is user convenience, since the main use case of this crate is seed generation.

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.

[newpavlov]

These functions can be helpful for seed generation and implementation of OsRng. Additionally, some backends (Hermit, RDRAND, RNDR, WASI p2) can directly generate random u32/u64 values. Relying on the byte API may be less efficient in these cases.

Using u32 and u64 as function names may seem problematic, but based on the fastrand experience, it works well in practice, provided that users reference them as getrandom::u32/u64 without importing them directly.

[newpavlov]

cc @dhardy@briansmith

[dhardy]

@newpavlov maybe though not really important for rand_core (we can already convert from bits). In any case, I won't depend on this until a new release is out so don't expect it to see use in rand v0.9.0.

[newpavlov]

@dhardy
My plan is to release getrandom v0.3 before before rand v0.9. You will not be able to silently migrate from v0.2 to v0.3 even with rust-random/rand#1537 because of the changes around optional backend handling.

[dhardy]

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 use get_random_u64 then... 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.

[newpavlov]

The main motivation is user convenience, since the main use case of this crate is seed generation. The u32/u64 generation support by some platforms is just an additional argument for why it should be done in this crate.

[dhardy]

The main motivation is user convenience, since the main use case of this crate is seed generation.

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.

[newpavlov]

These functions can be helpful for seed generation and implementation of OsRng. Additionally, some backends (Hermit, RDRAND, RNDR, WASI p2) can directly generate random u32/u64 values. Relying on the byte API may be less efficient in these cases.

Using u32 and u64 as function names may seem problematic, but based on the fastrand experience, it works well in practice, provided that users reference them as getrandom::u32/u64 without importing them directly.

[newpavlov]

cc @dhardy@briansmith

[dhardy]

@newpavlov maybe though not really important for rand_core (we can already convert from bits). In any case, I won't depend on this until a new release is out so don't expect it to see use in rand v0.9.0.

[newpavlov]

@dhardy
My plan is to release getrandom v0.3 before before rand v0.9. You will not be able to silently migrate from v0.2 to v0.3 even with rust-random/rand#1537 because of the changes around optional backend handling.

[dhardy]

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 use get_random_u64 then... 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.

[newpavlov]

The main motivation is user convenience, since the main use case of this crate is seed generation. The u32/u64 generation support by some platforms is just an additional argument for why it should be done in this crate.

[dhardy]

The main motivation is user convenience, since the main use case of this crate is seed generation.

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.

[newpavlov]

These functions can be helpful for seed generation and implementation of OsRng. Additionally, some backends (Hermit, RDRAND, RNDR, WASI p2) can directly generate random u32/u64 values. Relying on the byte API may be less efficient in these cases.

Using u32 and u64 as function names may seem problematic, but based on the fastrand experience, it works well in practice, provided that users reference them as getrandom::u32/u64 without importing them directly.

[newpavlov]

cc @dhardy@briansmith

[dhardy]

@newpavlov maybe though not really important for rand_core (we can already convert from bits). In any case, I won't depend on this until a new release is out so don't expect it to see use in rand v0.9.0.

[newpavlov]

@dhardy
My plan is to release getrandom v0.3 before before rand v0.9. You will not be able to silently migrate from v0.2 to v0.3 even with rust-random/rand#1537 because of the changes around optional backend handling.

[dhardy]

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 use get_random_u64 then... 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.

[newpavlov]

The main motivation is user convenience, since the main use case of this crate is seed generation. The u32/u64 generation support by some platforms is just an additional argument for why it should be done in this crate.

[dhardy]

The main motivation is user convenience, since the main use case of this crate is seed generation.

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.