I agree with this. IMO, everything that needs a (secure) PRNG should take a reference to the PRNG as a reference so that the caller can choose which implementation to use.
The presence of
rand::random() is at odds with this. Realistically, however, people are going to want something like
rand::random(); crates that use ring’s
ring::rand API often manually implement the equivalent of
rand::random() on top of it, for example. Thus, I think it might make sense to retain
rand::random() in light of this. However, that doesn’t mean it needs to be especially fast.
std::HashMap doesn’t follow the aforementioned rule of taking a
&rand::RNG) during construction, so it has to use
rand::random() unless/until new constructors are added for it. IMO it is acceptable to regress performance for the current constructors when adding the new constructors, but perhaps not everybody agrees. I expect there would be a lot of objections to forcing fast
HashMap construction to require a
&rand::Generator, since that would mean that all code that can construct
HashMaps would need to thread the
&rand::Generator through, which I think people will think is awfully inconvenient, especially since they probably don’t care about this issue as much as I (we?) do.