Tracker: rand 0.9

[vks]

Blocker:

• 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
• 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
• 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
• Possibly Optimise Rng::gen for arrays #1282
• Full update of weighted index by assigning weights #1194
• Upgrade criterion Upgrade criterion #1329

Non-breaking TODOs:

• Apply rustfmt and fix Clippy warnings #1448
• 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

[dhardy]

I'd like to get #1299 solved one way (#1301) or another (#1462 — assuming I can convince people that the differences between open and closed ranges are unimportant for floats), then I think we can drop a Beta release.

[SUPERCILEX]

It sounds like numpy allows returning the exclusive bound of a range, so doing #1462 seems reasonable especially since it probably improves performance.

[WarrenWeckesser]

@dhardy, sorry for disappearing for so long. I can take another look at the uniform changes this weekend (probably Sunday), but don't wait for me if you want to get the release out sooner!

[dhardy]

Our to-do list is now done (excepting replacing ChaCha code with the chacha20 implementation, for which it's been requested we release the next rand version first).

One last thing I'd like to solve, however, is usize / isize non-portability (#1399). To that end I have opened #1471, though I release that approach may be unpopular. Opinions on that PR please.

I'm away on holiday from Thursday and would love to make a beta release of v0.9 before then.

[dhardy]

I have published an alpha: https://github.com/rust-random/rand/tree/0.9.0-alpha.2 (master + #1471 + #1480 + a couple of tweaks to Cargo.toml).

[dhardy]

Alpha anouncement: https://www.reddit.com/r/rust/comments/1egixd9/rand_v09_alpha_usizeisize_support/

[SUPERCILEX]

Can https://github.com/rust-random/rngs get alpha releases too? Pretty sure it's not possible to upgrade if use something like rand_xoshiro. Then again might be a bit of a pain, so could wait for the full release.

[hsn10]

Create MSRV policy and hardcode dependencies, otherwise you can lose MSRV if dependency upgrades its MSRV in minor version.

I am happy with any MSRV <= 1.60. Usually 1.56.0 is used for simple crates because its lowest 2021 edition.

[dhardy]

I marked that whole discussion off-topic (the short version is that we will not be pinning dependencies).

Our MSRV policy is basically just "at least a year old at the time of the next Rand release, and consider other factors". In effect, I decide.

We are open to a PR reducing the MSRV to 1.60, assuming there isn't too much fallout. #1513

[dhardy]

PR for beta release: #1535

[newpavlov]

It may be worth to bump MSRV to 1.63 following the libc bump: rust-lang/libc#4040