Repository navigation
gen_range doesn't take a Range #744
Description
Is there a reason https://docs.rs/rand/0.6.5/rand/trait.Rng.html#method.gen_range doesn't take an std::ops::Range? This would be more convenient for specifying inclusive/exclusive boundary behaviors (e.g. 128..=255u8).
Activity
TheIronBorn commentedon Feb 23, 2019
gen_rangehas to allow types which don't implementRange.You can use ranges with
Uniform::fromthough:NOTE: this isn't an exact copy of
gen_range.gen_rangeusesUniform::sample_singlewhich isn't possible with this syntaxTheIronBorn commentedon Feb 23, 2019
Uniform:::new_inclusivealso existsdhardy commentedon Feb 23, 2019
In part it's historical, and since Rust doesn't support function overloading / multi-functions, we can't allow both. Maybe
rng.gen_range(1..=6)would be nice to have, but I think this is too widely used a function to bring a breaking change.samyakb commentedon Apr 3, 2019
@TheIronBorn if
Uniform::new_inclusiveworks for you then maybe there is no need to userng.gen_range(1..=6). I'm a beginner I don't know if there is any performance difference between thw two methods, if that's a case then maybe we can implementrng.gen_with_range(1..=6)dhardy commentedon Apr 5, 2019
@hmble there is potentially some performance difference;
UniformSampler::sample_single(low, high, rng)is designed to be faster (for single use) thanUniform::new(low, high).sample(rng).But is it worth having both
rng.gen_range(1, 7)andrng.gen_with_range(1..=6)? If so, should it begen_from_rangeor justfrom_range?samyakb commentedon Apr 5, 2019
@dhardy I guess no its not. IMO we can always use
rng.gen_range(start, end+1). Is there any case where we cannot use this approach ? If we decide to implement a method thenfrom_rangewould be nice method name.vks commentedon Apr 7, 2019
samyakb commentedon Apr 7, 2019
It seems a good choice to create another method
from_rngdhardy commentedon Apr 8, 2019
While @vks has a theoretical concern, I don't know how much it is a real concern, and there are workarounds (check the upper-bound or use
Uniform::new_inclusive).We could add another method like
sample_range, but this implies the need for a new function likeUniformSampler::sample_single_inclusive. I'm not too keen on adding more functionality there, and we can't simply change the meaning of the bounds (the type of breaking change causing bugs).dhardy commentedon Jun 4, 2019
I think there are basically two options on this one:
We keep the status quo. This is reasonably flexible since:
Uniform<X>: From<Range<X>>rng.gen_range(rng.start, rng.end)Uniform::newandUniform::new_inclusiveWe switch
rng.gen_rangeandUniform::newto support anyB: RangeBoundsand dropUniform::new_inclusive. This:Range<T>only requires thatT: PartialOrdwhich is already satisfied by all types supported byUniform)If not for the breaking change, the second option might be better (though would have to see an implementation first). However, I don't think it's enough better to justify this breaking change?
There is a third option: keep
Rng::gen_rangeas-is but addRng::gen_boundsor similar, and either adjustUniform::newor addUniform::new_bounds. However, this adds redundant code and API which we prefer to avoid (we already have a large API).vks commentedon Jun 4, 2019
I think we should probably go with option 2 before Rand 1.0. However, for now I think we should spend our budget for breaking changes elsewhere.
vks commentedon Aug 28, 2020
Rng::gen_rangenow takes an inclusive or exclusive range.