Implement From<RangeInclusive> for Uniform

[vks]

This syntactic sugar would allow to use Uniform::from(1..=10) instead of Uniform::new_inclusive(1, 10), but requires Rust 1.26. I don't think it is worth it to add a feature or raise the minimum required Rust version, but at some point we might want to implement it.

The implementation itself is trivial:

impl<X: SampleUniform> From<::core::ops::RangeInclusive<X>> for Uniform<X> { 
    fn from(r: ::core::ops::RangeInclusive<X>) -> Uniform<X> {                        
        Uniform::new_inclusive(r.start, r.end)                               
    }                                                                        
}                                                                            

[dhardy]

Good idea.

This is at least the third incentive I've come across to require Rust 1.26, although we don't need it.

[vks]

This is at least the third incentive I've come across to require Rust 1.26, although we don't need it.

I think we should have a release with all the new features possible without bumping the minimal version. The idea is to make adoption of the new API more likely for crates caring about this.

[pitdicker]

We already have the nightly feature flag, maybe it makes sense to implement it under that (for now)?

[vks]

That would work, however this does not actually require nightly, just Rust 1.26, so it would be a bit weird. Maybe better than nothing? We could also introduce a stable feature flag, which could be used for SIMD as well.

Unfortunately, we don't have conditional compilation for Rust versions AFAIK.

[sicking]

You still can't access .start and .end other than on nightly.

However as of Rust 1.27 you can use .start() and .end().

[dhardy]

We could also introduce a stable feature flag

I would prefer to have a rust_1_26 feature flag which gets deprecated once the minimum is or is greater than this version. But it is probably unnecessary.

[vks]

I would prefer to have a rust_1_26 feature flag which gets deprecated once the minimum is or is greater than this version. But it is probably unnecessary.

We could reuse this for SIMD though, which I think would make it worthwhile.