Tracker: rand 0.9

[vks]

Blocker:

• Zerocopy v0.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
• Replacing rand_chacha with chacha20 Replacing rand_chacha with chacha20 #1348 chacha20: returning rand_core feature RustCrypto/stream-ciphers#333
• 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

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
• Possibly Optimise Rng::gen for arrays #1282
• Full update of weighted index by assigning weights #1194
• Upgrade criterion Upgrade criterion #1329
• Improve calculation of the scale parameter for the uniform float distribution. Improve calculation of the scale parameter for the uniform float distribution. #1301
• Uniform Generator hangs for certain limits. #1299

Non-breaking TODOs:

• Use rustfmt (with #[rustfmt::skip] as appropriate): wait until number of open PRs is reduced
• Equidistant sampling of uniform FP values #1270

[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

[vks]

I don't think #1399 is a blocker, it's one of the caveats of using usize. I think we can fix it, and it would be a value-breaking change, but I would be fine with leaving this for Rand 0.10. If we just add gen_index, it would not even be a breaking change.

[dhardy]

Fair point, although we already have value-breaking changes here.

zerocopy may be our biggest blocker right now anyway (see update at the very top of this issue).

[josephlr]

We are looking at updating the getrandom implementation on Windows to match that in libstd: rust-random/getrandom#414

The simplest way to implement this is to use raw-dylib which was only stabilized in Rust 1.71 (released July 2023). We were considering releasing a release of getrandom which bumped the MSRV to 1.71. Would that be too new for rand 0.9?

CC: @newpavlov

[dhardy]

At the rate we're going, that may still be a year old by the time 0.9 is ready (though I hope not).

I am not aware of any hard constraints here.

[joshlf]

Fair point, although we already have value-breaking changes here.

zerocopy may be our biggest blocker right now anyway (see update at the very top of this issue).

Is there a reason you can't use zerocopy 0.7.32? What 0.8 features do you need? Maybe we could backport things to 0.7 to unblock you?

[joshlf]

Update: I've submitted #1446; at least as of the current state of master, 0.7.33 works, which I hope can unblock you guys.

[dhardy]

It might be worth deciding whether to adopt #1424 before the next release. (Comments welcome.)

I was also hoping to see the migration to chacha20. Not sure exactly where that's at. @tarcieri?

[tarcieri]

We've merged RustCrypto/stream-ciphers#333 which re-adds rand_core support.

However, it will probably still be some time before we cut a release, and one of the potential blockers on such a release is if we should upgrade to a prospective rand_core v0.7 first