Tracker: 0.8 release

[dhardy]

To resolve:

• reduce ChaCha crate dependencies rand_chacha and reducing dependencies #872
• rand_core::Error type and no_std diagnostics rand_core:0.5.0::Error has no raison d'etre #837
• Value stability: Value stability of distributions #786
• gen_range and ranges: gen_range doesn't take a Range #744, Implement Distribution for Range(Inclusive) #821 and gen_range(a, b) -> gen_range(a..b) and gen_range(a..=b) #1003
• Update to getrandom v0.2 (if released)
• Fix StdRng performance Simd not used for rand_chacha #1017
• Consider to deprecate SmallRng or use a better algorithm (see Investigate replacements for SmallRng algorithm #910)
• Use-after-free using ThreadRng from a thread-local destructor (Use-after-free when using a ThreadRng from a std::thread_local destructor #968)
• Release rand_core 0.6 (Tracker: rand_core 0.6 #1029)

Nice to have:

• Weighted sampling without replacement Implement weighted sampling without replacement #596
• Look into range sampling: new UniformInt bound checks #592, New publications on integer range sampling and shuffling #570
• Multiple distributions & naming: Compromising accuracy and speed [distributions] #494, HighPrecision<f32/64> #531, Optimize Cauchy sampling #493, WeightedIndex distribution naming #763
• Bit-level counter for BlockRng Add next_bool method to RngCore and counter levels to BlockRng #1031

Final changes for 0.8:

• Stop forwarding WASM features Stop forwarding getrandom's wasm features #886
• remove deprecations
• restrict ReseedingRng to std (see Possible atomicity violation in reseeding register_fork_handler #911)
• feature-gate StdRng (see next comment)
• Prefer 12-round ChaCha: rand_chacha: consider ChaCha12 (or possibly ChaCha8) over ChaCha20 #932
• Write updating guide (Updating guide for Rand 0.8 book#28)

---

There is still scope for additional changes before 0.8; most of the above don't require a breaking release to deliver.

[Nemo157]

Could StdRng be placed behind a feature gate to drop the rand_chacha dependency completely with default-features = false? When writing a library that uses rand but only exposes functions generic over Rng/RngCore I don't want to be pulling in any specific generators.

[dhardy]

Yes, I guess we can do that. Similar to small_rng, add a std_rng feature, with the difference that std implies std_rng.

[dhardy]

By the way, if any observers wish to help get this release ready sooner, one of the easiest ways to contribute may be to review pull requests. So long as you have some familiarity with the Rust language and Rand's API, reviews may be useful.

[newpavlov]

I think updating to getrandom v0.2 also should be added to the list.

[dhardy]

Thanks for pushing to get a lot of changes for 0.8 finished @vks. I guess we can be flexible on the "Multiple distributions & naming" items.

At the moment it's not obvious (to me) whether we'll want a 0.9 release with more breaking changes before 1.0. It may be nice to essentially make 0.9 the beta for 1.0. I don't envision too many more changes needed to the core rand crate, though there are still many issues open.

[vks]

We should probably also deprecate SmallRng or use a better algorithm (see #910) for this release.

At the moment it's not obvious (to me) whether we'll want a 0.9 release with more breaking changes before 1.0

I agree that rand is stabilizing, the only think I can think of that may need a bit more iteration is #989 (adding more convenient/simple methods). And we should possibly release getrandom 1.0 and rand_core 1.0 before.

[vks]

Another thing to consider for this release is adding support for entropy-efficient bool generation to BlockRng, see #1014. This may require adding a next_bool method to rand_core::RngCore.

[vks]

I updated the tracker and opened #1027 and #1028 for some of the remaining issues. I added #1017 to the important issues and demoted the multiple distribution issue to nice-to-have, since we will likely implement this in rand_distr anyway.

After my two PRs are merged and the StdRng performance is fixed (#1017), I think we can release 0.8, unless we want to include some of the ideas from #1014.

I don't know what the status of getrandom 0.2 is, but it does not seem to have materialized so far, so maybe we can keep this for a later release.

[dhardy]

I believe @josephlr was intending on getting getrandom v0.2 out soon?

[vks]

@dhardy SmallRng seems to be the only remaining blocking item. Should we deprecated it? It does see some use in the wild. Alternatively, we could replace the PCG algorithm with xoshiro{128,256}++ (for 32-bit and 64-bit systems). Should this include moving rand_pcg to the rngs repository? Instead of depending on rand_xoshiro, we could also just inline the corresponding implementation.

[dhardy]

PCG's main failing is that streams are too similar. Xoshiro isn't perfect either: it can struggle with mostly zero seeds. That shouldn't happen, especially since we have seed_from_u64, but as we saw in a recent bug report it still does. So maybe we should deprecate it and add FastRng = ChaCha8? But that would still be a bit misleading since ChaCha relies on SIMD for speed which isn't always available.

Lets take discussion back to #910.

[vks]

Xoshiro isn't perfect either: it can struggle with mostly zero seeds.

I think this is true for most non-crypto RNGs? It takes xoshiro{128,256}++ ca. 10 samples to escape from zeroland, which is relatively low.

[dhardy]

Yes, and not everyone realises that, which is a point in favour of deprecating SmallRng.

[josephlr]

Status on getrandom 0.2. The code is done, the only remaining steps are:

• Final docs review (see Update docs for 0.2 Release  getrandom#135) in progress
• Publishing on https://crates.io (@dhardy / @newpavlov I can do this if you invite me to manage the crate)

Note that if we decide to have getrandom 0.2 as part of rand 0.8, we should also make sure our features are set/documented correctly. We have already removed the rand_os/wasm-bindgen, rand_os/stdweb, rand/wasm-bindgen, and rand/stdweb features.

Would we still want getrandom to still be an optional dependency of rand_core? Of rand? Note that getrandom now supports all targets by way of Custom RNG hooks.

[vks]

I would prefer getrandom to be optional, some users might prefer not to have it in their dependency tree if they want determinism.

[newpavlov]

@josephlr

I can do this if you invite me to manage the crate

Since you are a member of the maintainers team, you should have sufficient rights.

Would we still want getrandom to still be an optional dependency of rand_core?

I also think that it should be an optional dependency.

[josephlr]

Sounds good on keeping getrandom optional (both for rand_core and rand). I'll update everyone when 0.2 is out.

[josephlr]

Getrandom 0.2 has been released: https://docs.rs/getrandom/0.2.0/getrandom/

[vks]

I think we still need to release rand_core 0.6, which migrates to getrandom 0.2. Is there anything else left to do for this release?

[dhardy]

Not that I am aware.

[newpavlov]

How about removing the random method and introducing it later in the helpers module (see #989)?

[dhardy]

That would be a pain for anyone updating to 0.8.0 that used random, @newpavlov. And please keep that discussion in the topic thread.

[djc]

This looks like it's pretty much ready to go -- is there anything I can do to help move this forward?

[dhardy]

You're right, I believe it is ready to go. It would be nice to have #1066 but that's definitely not a blocker.

@vks @newpavlov any objections or shall I go ahead with the releases (rand_core and rand, and version bumps for the necessary rng crates)?

[newpavlov]

I think we should decide on #1031 (merge, close or postpone until rand_core v0.7). Also it could be worth to do some cleaning in getrandom v0.2, namely removing Windows XP and stdweb support.

[dhardy]

I was thinking we postpone #1031, but we don't necessarily have to if it can be resolved in short order.

Is there good reason to drop WinXP and stdweb support from getrandom before the rand release? Either its considered a breaking release or its not. We could even bump rand_core v0.6.1 to use getrandom v0.3 if you go that route — except that if getrandom considers removing platforms a breaking release, it would be a bit odd for rand not to do the same.

[newpavlov]

I thought about keeping getrandom v0.2.0 as an escape hatch for users who may require WinXP or stdweb support. So while officially we will not support them, they will be able to pin getrandom to the old version if needed.

[dhardy]

In that case it affects rand even less. So... ?

[newpavlov]

It would've been nice to mention such changes in rand v0.8 announcements and release notes for better visibility, but it's not in any way a critical blocker, so I am not opposed to cutting releases now.

[dhardy]

In any case, we can go ahead with the rand_core v0.6 release as well as PRNG crates.

[dhardy]

v0.8 has been released.