Tracker: rand_core v0.10

[dhardy]

This issue tracks breaking changes for rand_core v0.10 and other potential changes for v1.0.

Breaking changes scheduled for v0.10:

• Bump MSRV and Edition for rand_core rand#1668
• Move rand_core::impls::* to le rand#1667
• Move fn read_adapter out of trait TryRngCore rand#1669
• Move OsRng down to rand rand#1674
• Simplify trait BlockRngCore and rename to Generator #26
• Remove optional feature serde #28
• Reduce block code #34
• Replace mod le with utils #38
• Revise index / reset / skip methods #44
• Let RngCore: TryRngCore<Error = Infallible> #45
• Support ?Sized types in Rng*: TryRng* blanket impls #51
• Remove fn unwrap_mut #53
• Rename (Try)RngCore to (Try)Rng #54
• Use core::error::Error bound for TryRng::Error #58

Problematic/blocked changes (more likely to hit v2.0 than v1.0):

• Can we merge BlockRng64 and BlockRng with impl<R: BlockRngCore<Item = u64>> RngCore for BlockRng<R>? No; firstly because Rust does not yet recognise that R: BlockRngCore<Item = u32> is distinct from R: BlockRngCore<Item = u64> and secondly because BlockRng64 has a half_used field. See Reduce block code #34.
• Can we replace usages of UnwrapMut with UnwrapErr<&mut Self>? It appears not since we don't have impl<R: TryRngCore> TryRngCore for &mut R (see next item). See Let RngCore: TryRngCore<Error = Infallible> #45, Remove fn unwrap_mut #53.
• Can we have impl<R: RngCore> RngCore for &mut R? No; it conflicts with impl<R: RngCore + ?Sized> TryRngCore for R since Rust does not yet support overlapping blanket impls (e.g. specialisation). See Let RngCore: TryRngCore<Error = Infallible> #45.

Other possible changes:

• Rename Rng -> RngExt, RngCore -> Rng rand#1288
• rand_core: introduce Seed trait rand#1670
• Further block module revisions. Little motivation in my opinion.
• Tracker: proposed RngCore changes rand#1261

[dhardy]

Non-API-breaking changes:

• Remove doc section titled "Implementing SeedableRng for RNGs with large seeds". This is problematic only in that arrays of more than 32 elements do not currently implement Default. This limitation may be fixed soon; see Use const generics for array Default impl rust-lang/rust#61415.

[dhardy]

A pre-release of v0.10.0 is out now.

[dhardy]

Everything on my to-do list for the next release is done so I opened a PR for v0.10: #22 (date: next Sunday).

If no issues crop up, I'd like to re-release the same code as v1.0 six weeks after rand v0.10 is published. rand_core v0.10.x would then become a compatibility shim over v1.0.

[newpavlov]

As I wrote previously, I would prefer to have a larger "cool down" period (1-2 years). Assuming that we will promote v0.10 to v1.0 without any changes, migration with the semver trick should be relatively transparent for downstream users. But it's not a strong opinion, so if others disagree, I would be fine with the six weeks plan.

[tarcieri]

It’s difficult to bump all of the RustCrypto crates and requires a lot of coordination. I’m still not done, as it were. I’d personally prefer we do what newpavlov suggests.

[dhardy]

The release of 0.10.0 will have to be delayed due to #24; we'll need a new pre-release and validation phase.

We can extend the 1.0 validation phase beyond six weeks, though 1-2 years is rather long in my opinion.

[tarcieri]

We can extend the 1.0 validation phase beyond six weeks, though 1-2 years is rather long in my opinion.

If it's going to be longer than 6 weeks, I'd rather it be a year or longer. We don't want to be immediately cutting a bunch of breaking releases after bumping everything to rand_core v0.10.

That said, if it's only an additional 6 weeks after rand_core v0.10, I can wait that long if it means we get rand_core v1 out of the deal.

[dhardy]

We seem to be making more extensive changes to rand_core than I had expected, so a long validation phase makes sense now.

[dhardy]

I'm considering a split stabilisation strategy: we keep only stable items (I think just traits RngCore, CryptoRng) in rand_core, and move everything else to a new crate rand_core_extras which pub-reexports everything from rand_core. That way:

• People only needing stabilised components can use rand_core v1.0 soon
• Everyone else migrates from rand_core v0.9 to rand_core_extras (or whatever we name it) v0.10
• This is already enough that RNGs will be compatible across rand_core_extras versions, though seeding-support and ReseedingRng support will take time
• Once components are sufficiently stable (say, have been in a published version for over a year without modification and we have no intention to modify further) we can move them to rand_core in a patch release