rand_core::block

[dhardy]

Related to #655 and #648, I have been considering whether we should remove the "block" stuff from rand_core to another crate, say rand_block.

• Rationale: it's a significant amount of extra code that not all users need, and rand_core is supposed to be a minimal interface crate.
• Against: the main users wanting a minimal interface are likely to want CSPRNGs anyway.

[dhardy]

Note: this is in part motivated to prepare rand_core for 1.0 stabilisation, but it may be best to wait until we have resolved #648 / have a "secure random" function within std, since this may have consequences for our core traits or error types.

[burdges]

Almost all PRNGs work this way, so the issue is providing the right block stuff. There is no harm in folks who want only OsRng importing the block stuff but simply not using it. If you want iterators then you pull in iterator adapters too.

[dhardy]

No, simple non-crypto PRNGs generally don't use a buffer. But even so it seems common enough code to be worth keeping in rand_core.