Repository navigation
Towards rand 1.0 #232
Description
We've had questions about when Rand will reach 1.0. We're not there yet, but it is still worth discussing the dependency on getrandom.
From memory & quick skim the only part of the API which is affected by getrandom is rand_core::Error, and only in two ways:
- The declared constants must match those in
getrandom::Error. This doesn't really requiregetrandomto be 1.0 so long as there is a stability promise affecting these. impl From<getrandom::Error> for Error, which thus pinsrand_coreto a singlegetrandommajor-minor version.
Potential solutions:
- Stabilise
getrandom1.0 soon? Seems unlikely? - A separate crate just for
Error— perhaps viable but definitely not desirable - Use the promise above and deprecate that
impl, forcing users to rely ongetrandom::Error::code() -> NonZeroU32andimpl From<NonZeroU32> for Error
CC @vks @newpavlov
Activity
gilescope commentedon Oct 10, 2021
That error code looks a little like an enum with non-exhaustive on it?
vks commentedon Oct 10, 2021
I think the most important part of our API affected by
getrandomis actuallySeedableRng::from_entropy.Why is stabilizing
getrandom1.0 unlikely?dhardy commentedon Oct 11, 2021
from_entropyandOsRngare not re-exporting anygetrandomsymbols. They use it internally, but that's fine because bumping thegetrandomversion inside a patch-release ofrand_corewon't cause problems there — but it can with thatFrom<getrandom::Error>impl.Essentially, yes. But one that's user-extensible (e.g. by a custom backend) without any crate dependencies. Go read #3.
gilescope commentedon Oct 11, 2021
Thx for that history pointer. A stability promise on the existing constants seems pretty uncontroversial? New ones could still be added...
josephlr commentedon Oct 15, 2021
As one of the maintainers, I would be fine committing to stability for the numerical constants. Specifically something like "these constants will not change between now and 1.0", and we could put something like that in the
README.While this is true, it should be possible to have that API be stabilized without
getrandomnecessarily being in1.0. For example ifgetrandom's API changed (not that we really anticipate such a thing), you would just need a way to still implementfrom_entropywith the new API.I think removing the
impl From<getrandom::Error> for Errorwould be wise, as it seems redundant to have thatimplandimpl From<NonZeroU32> for ErrorPersonally, I don't think it's too unlikely, I would just want to resolve some outstanding issues before doing so. Specifically:
getrandom()really fall back to File I/O when the getrandom syscall returns EPERM? #229, It should be possible to use a custom implementation when RDRAND is available #230getrandomis a different issue (and shouldn't block stabilization).getrandomcrate m-ou-se/getrandom#1getrandomusage adopted bylibstdnewpavlov commentedon Oct 15, 2021
Also ideally before releasing 1.0 I think it's worth to have MSRV-dependent dependency version resolution implemented in Cargo, so it would be possible to bump MSRV without breaking builds on older toolchains.
gilescope commentedon Oct 15, 2021
Great work that's being done pushing this all forward. Mouse's review seemed very positive. Let me know if I can help in any way.
newpavlov commentedon Jun 19, 2024
As proposed here, another potential API change for 1.0 is to use
BorrowedBufinstead of&mut [MaybeUninit<u8>]forgetrandom_uninit.briansmith commentedon Jun 19, 2024
I don't know if it would make sense to change the public API to use BorrowedBuf/Cursor. I was suggesting there it might make sense to change the internal ones like
sys_fill_exact. Even then I'm not sure.newpavlov commentedon Dec 11, 2024
I think we can close this issue for now since most of the discussion is no longer relevant.
Before considering v1.0 we need to get some experience with
getrandomv0.3. There is also a possibility ofstdintroducing agetrandom-like API (see rust-lang/rust#130703) which would make this crate obsolete.When it will be the time for rand v1.0 release we can open a new issue to consider whether we should release getrandom v1.0 or not.