Tracking issue for the next breaking release

[newpavlov]

The next breaking release is likely to be v1.0.

Potential changes:

• Design of the block module. See Future of block module #71
• Use SEED_LEN associated constant in the SeedableRng trait instead of the Seed associated type. Blocked on stabilization of generic_const_exprs.
• Migrate from Infallible to !. Blocked on stabilization of the never type. (Could be backwards-compatible?)
• Set Infallible as default type for TryRng::Error. Blocked on stabilization of associated_type_defaults.
• Introduce WordRng trait with blanket impls for TryRng (see below). Conflicts with the blanket impl of TryRng for T: DerefMut<Target = impl TryRng>. Blocked on Can't write non-overlapping blanket impls that involve associated type bindings rust-lang/rust#20400, mutually exclusive traits and/or negative trait bounds.
• Remove UnwrapErr::re after support for reborrows is added to the language. See Some way to simulate &mut reborrows in user code rust-lang/rfcs#1403.

Rejected changes:

• Pass seeds by reference in SeedableRng instead of by value.
• Use "natural" seed types instead of byte arrays. See rand_core: introduce Seed trait rand#1670.

[newpavlov]

WordRng could look like this:

pub trait WordRng {
    type Word: Word;
    fn next_word(&mut self) -> Self::Word;
}

impl<T: WordRng<Word = u32>> TryRng for T {
    type Error = Infallible;
    // ...
}

impl<T: WordRng<Word = u64>> TryRng for T {
    type Error = Infallible;
    // ...
}

It allows to noticeably improve ergonomics of implementing infallible word-based PRNGs (the most common RNG class) and to remove several functions from the utils module.

The biggest blocker is overlap with the DerefMut blanket impl.

[elichai]

Why not remove the "word" abstraction, and directly buffer on-top of a BlockRng? so we have a trait BlockRng (similiar torand_core::block::Generator ) and we build a buffer above it that buffers bytes? then try_fill_bytes will be the only required method, with next_u32/u64 being provided? word sized rngs can have the word as the size of their block

[newpavlov]

Unnecessary buffering would be inefficient for RNGs which generate words as their output (e.g. PCG). Since they are usually performance-oriented, this inefficiency would be quite noticeable.