Tracker: rand 0.9

[vks]

Blocker:

• getrandom v0.3
• Zerocopy v0.8 — 0.8 Release Roadmap google/zerocopy#671

Planned breaking changes for rand 0.9 are:

• switch sample_single int to O'neill's modulo method & update gen_rang… #1154
• Make distributions in rand use Result (Error handling of distributions::Uniform::new #1195, API differences between Uniform and Bernoulli #1211)
• Bump MSRV to 1.56 and enable const generics by default
  • Bump rand_core minor version
  • Bump ranch_chacha, rand_pcg minor version
  • Bump rand minor version
  • Bump rand_distr minor version
• Add FromSeed trait
• RNG rename (likely reject) Rename Rng -> RngExt, RngCore -> Rng #1288
• Allow using std feature without bringing in getrandom and rand_chacha dependencies #1339
• Implementing SliceRandom::choose_multiple(_weighted) is impossible if you aren't simply forwarding the calls to an inner [T] #1307
• Remove automatic (delayed) reseed-on-fork #1379
• CHANGE: Rename Rng::gen to avoid conflicting with a keyword in Rust 2024 #1435
• Uniform Generator hangs for certain limits. #1299, solved by Improve calculation of the scale parameter for the uniform float distribution. #1301 or UniformFloat: allow inclusion of high in all cases #1462

Possibly also:

• Possibly Look into this alleged optimal algorithm for bounded random integers #1172
• Possibly fill_via_chunks: mutate src on BE (small optimisation) #1182
• Upgrade criterion Upgrade criterion #1329

Non-breaking TODOs:

• Apply rustfmt and fix Clippy warnings #1448
• Equidistant sampling of uniform FP values #1270

Not planned:

• Replacing rand_chacha with chacha20 Replacing rand_chacha with chacha20 #1348 chacha20: returning rand_core feature RustCrypto/stream-ciphers#333
• Possibly Optimise Rng::gen for arrays #1282
• Full update of weighted index by assigning weights #1194

[dhardy]

We should also conform to common Rust coding standards (generally expected of open projects now). I have argued against these in the past (some poor formatting and false-positive lints, verbosity of opt-outs), but the reasons not to use these are fewer (less active development) and reasons to do so greater (mature tools and very widespread usage):

• use rustfmt (with #[rustfmt::skip] where required), including CI check
• use Clippy (with required opt-outs), including CI check

I suggest only doing this late before v0.9 since both will cause significant merge conflicts and there is currently some on-going work.

[vks]

Fixing the clippy warnings is not a big deal, we are already doing pretty well. Also see #1197.

[dhardy]

We should consider bumping the MSRV to Rust 1.51.0 (March 2021), enabling usage of const generics by default.

[dhardy]

Question: do we make a breaking release of rand_core at the same time or stick with 0.6.x?

See my comment in #1269:

• Avoiding breaking changes to rand_core lets users upgrade to Rand v0.9 more easily (no need to touch RNGs)
• We may well make breaking changes to RngCore in the future, but likely not soon (most ideas floated depend on unstable language features)
• We cannot release 1.0 without getrandom 1.0
• Avoiding breaking changes effectively means we have two MSRVs and corresponding CI tests within the project, but this should be okay

[vks]

What breaking changes would we want to release for rand_core?

[dhardy]

Pending: #1182, #1267.

Possible future changes: #1261, and @newpavlov mentioned somewhere using const generics to re-write RngCore with a method like fn generate(&mut self, result: &mut [u8; Self::LENGTH]). (I can't find his comment.)

[newpavlov]

I also would like to rework a bit the crypto traits. We have some issues with them in RustCrypto, see: RustCrypto/traits#1148

[coolreader18]

Not sure if this would be the place for it, but in terms of major version bumps it'd be good to switch feature specifications over to weak feature dependencies ("dep?/feature" syntax) once the MSRV >= 1.60. Otherwise there's no actual way to e.g. enable std without also enabling rand_chacha as a dependency cause it's std = [.. "rand_chacha/std", ..]

[dhardy]

I guess we could go all the way to 1.60 (April 2022). We already have a PR for 1.56: #1269.

[dhardy]

Lets go with a breaking release for rand_core since we have a few proposed changes and no objections.

@coolreader18 feel free to make a PR with your proposed changes after the 1.56 PR is merged. I'm not certain yet we'll use 1.60 but think it's unlikely there will be a significant reason not to.

[SUPERCILEX]

Is it worth making a release with what we currently have? Selfishly, I'd like to be able to use my PRs, but it's also worth noting that the last release was in February 2022. I tend to prefer the regular release cadence approach rather than the wait for everything to be ready approach. Thoughts?

[dhardy]

I would like to get a release out soon, if only because we've had a lot of changes since the last release. Will have to review (and dedicate a bit of time to this).

[dhardy]

Update: a pre-release is planned.

I'd like to get a couple more significant changes in before the actual release:

• Remove automatic (delayed) reseed-on-fork #1379
• Switch to chacha20 (@nstilt1), though we shouldn't block release on this
• Ideally, Implementing SliceRandom::choose_multiple(_weighted) is impossible if you aren't simply forwarding the calls to an inner [T] #1307
• Ideally, Upgrade criterion #1329

[dhardy]

We should also resolve this, one way or another:

• Output of gen_range is platform dependent for usize #1399