-
Notifications
You must be signed in to change notification settings - Fork 172
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Towards rand 1.0 #232
Comments
That error code looks a little like an enum with non-exhaustive on it? |
I think the most important part of our API affected by Why is stabilizing |
Essentially, yes. But one that's user-extensible (e.g. by a custom backend) without any crate dependencies. Go read #3. |
Thx for that history pointer. A stability promise on the existing constants seems pretty uncontroversial? New ones could still be added... |
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
While this is true, it should be possible to have that API be stabilized without I think removing the
Personally, I don't think it's too unlikely, I would just want to resolve some outstanding issues before doing so. Specifically:
|
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. |
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. |
As proposed here, another potential API change for 1.0 is to use |
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 |
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
isrand_core::Error
, and only in two ways:getrandom::Error
. This doesn't really requiregetrandom
to be 1.0 so long as there is a stability promise affecting these.impl From<getrandom::Error> for Error
, which thus pinsrand_core
to a singlegetrandom
major-minor version.Potential solutions:
getrandom
1.0 soon? Seems unlikely?Error
— perhaps viable but definitely not desirableimpl
, forcing users to rely ongetrandom::Error::code() -> NonZeroU32
andimpl From<NonZeroU32> for Error
CC @vks @newpavlov
The text was updated successfully, but these errors were encountered: