Closed
Description
If we do this,
- direct users of
rand_core
might have issues (if they don't request thestd
feature and try to use missing functionality) - indirect users of
rand_core
(i.e. users ofrand
etc.) shouldn't notice any differences, so long as the direct dependencies use the feature correctly - this should help avoid problems like in Having
rand
0.5 andrand
0.6 with default features turned off in the crate graph results in a compliation error #645, where the build happens to requirestd
inrand_core
(likely accidentally) but not inrand
There isn't a lot of functionality in rand_core
which is enabled by the std
feature, but there is a little:
rand_core::Error::take_error
is definedrand_core::Error
implementsstd::error::Error
std::io::Error
implementsFrom<rand_core::Error>
RngCore
implementsstd::io::Read
Of course, this is potentially a breaking change, so we should bump the version number to 0.4.0 and have a shim 0.3 → 0.4 which still enables std
by default — except, since the change is unlikely to cause much breakage and we are already breaking some builds, I wonder if it is worth it?
Metadata
Metadata
Assignees
Labels
No labels