[dhardy]

• Added a CHANGELOG.md entry

Summary

Adds:

/// Construct and seed an RNG
///
/// This method yields a seeded RNG, using [`rng`] ([`ThreadRng`]) if enabled or
/// [`SysRng`] otherwise.
///
/// # Examples
///
/// ```
/// let mut rng: rand::rngs::SmallRng = rand::make_rng();
/// # let _ = rand::Rng::next_u32(&mut rng);
/// ```
///
/// # Security
///
/// Refer to [`ThreadRng#Security`].
#[cfg(feature = "sys_rng")]
pub fn make_rng<R: SeedableRng>() -> R { /* ... */ }

Motivation

We have removed SeedableRng::from_os_rng() since the last release. SomeRng::try_from_rng(&mut getrandom::SysRng).unwrap() is not exactly convenient to use.

We could put something like this under getrandom, but it feels more appropriate within rand (also allowing usage of ThreadRng).

Details

This is also slightly contentious, but I feel it's useful enough to be worth having. We could add trait SeedableRngExt instead, but that would have significantly more API surface.

[newpavlov]

Wouldn't it be better to introduce RngExt::from_sys_rng() -> Self where Self: SeedableRng?

[dhardy]

That would allow SomeRng::from_sys_rng(), but I prefer this since:

• RngExt is a surprising place to put from_sys_rng
• Using RngExt may require an extra import (<SomeRng as rand::RngExt>::from_sys_rng() is quite convoluted)

[mstoeckl]

LGTM. This looks like a relatively low impact change; I expect it will be hard to confuse with rand::rng (since that returns the non-seedable ThreadRng; and the documentation is clear in both cases.)

One possible issue is that SysRng isn't infallible, so this can panic... (but so can ThreadRng, on first use.)