generate_range panics if the upper bound is 0

[tesselode]

Example:

use nanorand::{tls_rng, RNG};

fn main() {
    println!("{}", tls_rng().generate_range::<usize>(3, 0));
}

Produces this output:

thread 'main' panicked at 'attempt to calculate the remainder with a divisor of zero', C:\Users\Andrew\.cargo\registry\src\github.zerozr99.workers.dev-1ecc6299db9ec823\nanorand-0.5.2\src\gen.rs:51:17
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

[Absolucy]

I mean, there's an assert anyways: https://github.com/aspenluxxxy/nanorand-rs/blob/7e1704e6a80697b7b4bda4d93a8a476748379463/nanorand/src/gen.rs#L49-L51

and there's currently no support for generating signed integers anyways, so this is expected behavior? where are your running into this?

[tesselode]

I ran into it on accident because I was trying to pick a random index of a Vec with length zero. It's fair that this would cause a panic, but the error message I got didn't point me towards the problem.

[Absolucy]

it should no longer panic.

[matklad]

If I am reading the code correctly, it’ll now return the lower bound for an empty range. I wonder if that’s the desired behavior?

Looking at the prior art, rand, fastrand and Python’s random all panic on empty ranges. At a first glance, panicking does make sense, and violating range.contains(&result) doesn’t.

Perhaps just the panic error message needs to be adjusted? It seems that (guessing here, the report isn’t supper clear) this is what tesselode is asking for, it’s not “make it non panic by returning something arbitrary”.

[tesselode]

Yeah, looking back, this was not a good issue report. An invalid range should cause a panic, it should just have a proper error message. I think I was confused about whether this should panic or not because the error message looked like it was caused by an internal bug, not user error.