Consider renaming RngCoreto BitRng

[vks]

Looking at the redesign of numpy.random, I realized that their API became more similar to ours. Their Generator class is almost equivalent to our Rng trait, and their BitGenerator class is very similar to RngCore + SeedableRng. I like their names more than ours, because BitGenerator seems more descriptive than RngCore. Maybe it is worth the churn to rename it to BitRng for Rand 1.0?

(Other observations are that their API allows for drawing an arbitrary number number of samples, which is more vectorization friendly than our API. It also seems like they deprecated their global RNG! They also added a SeedSequence class (based on this), which is similar to rand_seeder.)

[dhardy]

No, I don't think the name is sufficiently better to justify this kind of API churn. BitRng is also not as clear in purpose as BitGenerator.

We already do have a way of extracting arbitrary amounts of random data: fill_bytes. Sure, we still don't have nice APIs for stuff like filling a matrix with uniform samples from 0..1, but that's probably more a feature for a linear-algebra library (as in numpy).

There are some rationales for removing our thread_rng (e.g. #968, #996), but for the most part those are solvable bugs, and the only real limitations are (1) some memory usage per thread (though very little when not used), (2) embedded compatibility without standard thread/sync machinery — though for the most part the main rand lib is not embedded friendly anyway and (3) code size — though we would still import ChaCha for StdRng so this shouldn't be a big deal.

So... no to all suggestions?

[newpavlov]

Even not considering the churn, I disagree that BitRng is a better name than RngCore. I think think that it will be confusing, because I for one would read it "RNG for generating bits".

[dhardy]

So lets close this.