I still think the new() method is great to have. Maybe we just need to sell it a little better.

The new trait NewRng makes functionality we already had for StdRng easily available to all seedable RNG implementations. It provides easy seeding of PRNGs using EntropyRng as source, which internally uses OsRng or a fallback.

If we decide to change anything here, NewRng::new_fresh() is something I could get behind.

But always good to try to do something with critique, and see if we can get something better. So 👍 for the PR.

What do you think of having two methods in NewRng: new_fresh and from_thread_rng?

I was thinking about that; there's some sense to it but I'm not sure; it's not a lot easier than writing from_rng(thread_rng())? and there's a chance we could move thread_rng into a separate crate later.

it's not a lot easier than writing from_rng(thread_rng())?

No, it is not for us. But it takes two imports (rand::{SeedableRng, thread_rng}, two methods (SomeRng::from_rng and thread_rng(), and some way to handle errors (? or unwrap()). SomeRng::from_thread_rng would be one method and one import NewRng.

I don't care all that strongly. But I believe such a convenience method would put both source on a more even foot.

there's a chance we could move thread_rng into a separate crate later.

That idea is new to me. What would be the reason for doing something like that?

thread_rng is a derived component so would be easy to separate out (apart from this usage), but probably there's no value in doing so.

So maybe as follows:

pub trait NewRng {
    // both methods panic on error since this trait is pure convenience:
    fn from_entropy() -> Self;
    fn from_thread_rng() -> Self;
}

Reasoning:

• from_* type methods are commonly used to construct an object from something else (e.g. from_str, from_iter)
• as @pitdicker points out, a single method is easier to remember, less to import, and expecting users to call unwrap() or handle extremely unlikely errors (which often can't be worked around properly anyway) is not ideal, so there is some value in these
• the trait is for constructing RNGs so the name does seem appropriate; also FromEntropy::from_entropy is redundant naming (poor design) and FromEntropy::from_thread_rng doesn't make much sense

@vks @burdges @huonw any thoughts?

What's the difference between the two methods?

One uses EntropyRng for external entropy and the other uses the local thread_rng for fast "entropy" from a crypto rng.

I prefer something with fresh in the name, as you suggested in the first comment, over from_entropy.

It sounds more approachable, and I have my doubts whether "construct an RNG from entropy" is a correct expression.

If we go with from_entropy we have several similarly-named ways of constructing RNGs:

• SeedableRng::from_seed
• SeedableRng::from_rng
• FromEntropy::from_entropy
• FromEntropy::from_thread_rng — possible addition

Contrary to what I said earlier, the redundant name FromEntropy::from_entropy is helpful to describe where the method comes from (if seen like SmallRng::from_entropy()), and FromEntropy::from_thread_rng still makes some sense (thread_rng is used as an entropy source).

So I'm tempted to merge this PR as is, or possibly with the from_thread_rng addition.

So I'm tempted to merge this PR as is, or possibly with the from_thread_rng addition.

👍 for merging as is.

StdRng::from_thread_rng() should probably be avoided, so I'm not sure from_thread_rng is a good idea. I think I would rather err on the side of caution and mention the benefits of from_rng(thread_rng())? in the documentation of from_entropy.

On an unrelated note, does it make sense to rename thread_rng to ThreadRng::new()? This seems more consistent with JitterRng, EntropyRng and OsRng.