I noticed in the latest rust-analyzer release that they use oorandom to shuffle indices, which they do with casts between u32 and usize.
It might be nice if oorandom had native support for this, something like RandSize that wraps either Rand32 or Rand64 according to the target pointer width. It would have integer methods rand_usize and rand_isize, no need for floats, and the rest of the API would be the same. I'm not sure what would be best for seed and state types though...
Sorry for the long delay, apparently I don't get emailed when tickets happen here... Need to fix that.
It's a nice idea. I'm not sure it's something that should be added though. It's a fair amount of extra API for a fairly small feature, it's a feature that isn't going to be used super commonly, and a user can write their own wrapper to choose the right rand size based on pointer width pretty easily. So I like it, but in the interests of minimalism I don't see a compelling reason for
oorandomto include it.
No problem, thanks for considering it.
Yeah, I feel this is XY problem. What we need in rust-analyzer is to shuffle a slice. It'd be nice if oorandom had knuth-shuffle built-in in some form. Granted, Knuth shuffle is a trivial algorithm, and one can just write it,... except that it took me like four tries to not mess it up :D
Yeah, I've considered adding a "shuffle" function before... That one is far more tempting. On the other hand, that's also still the definition of feature creep. XD But it does solve a few real problems... As you said, it's a trivial algorithm but still worth putting the effort in to not mess up, and there's a bit of finesse to be had with handling
usizecorrectly. This is going to bug me for ages now...
...My current urge is to say "a shuffle function doesn't generate random numbers, so doesn't belong in oorandom". Harsh but simple policy against feature creep. Though then, where does it belong? A feature flag? A separate crate?