Apparently rand 0.9 ripped out the implementations for isize and usize on some platforms. Very unexpected and a pain to deal with for libraries (particularly for macro-generated code).
![Feature gate: #![feature(random)] This is a tracking issue for secure random data generation support in std. Central to this feature are the Random and RandomSource traits inside core::random. The ...](https://files.mastodon.social/cache/preview_cards/images/134/320/315/original/47187a45adb6d3f6.png "Feature gate: #![feature(random)] This is a tracking issue for secure random data generation support in std. Central to this feature are the Random and RandomSource traits inside core::random. The ...")
@jhpratt that crate seems to have had a history of having a very “agile” API. Not a biggie since it’s by definition <1.0, but I just ended up hard-pinning it in my projects where the need is just an ignorant “give me some kind of random thing of this type”
@ayourtch Not feasible for libraries.
@ayourtch @jhpratt for most users you could also copy paste the 10 lines of RNG code you actually need and avoid the entire problem by construction... It seems trite but honestly people tend to have very basic rng needs in practice, and the people who don't, aren't likely to want to give up the control anyway. Overcooked!
@jhpratt @ayourtch yeah i can see it's going to be a bit annoying for (i assume this is about `time`) libraries just because people want to use the common rand crate with whatever common other libraries, and you're then strapped to the bad decisions. but it's also one of those things where i just extremely struggle to see the actual value to using something like rand that's like... innately fragile, impossible to please everyone api wise, and trivial in practice to re-implement as needed.
@jhpratt Do you know the reason perchance?