Minimum rustc version

[dhardy]

Upstream rand has an explicit Travis test on Rustc 1.15.0. This branch won't compile on anything older than 1.18.0. Reasons:

• pub(crate) syntax was stabilised in 1.18.0
• struct field short-hands were stabilised in 1.17.0
• use of $self in macros; keyword recognition appears to be more restrictive before 1.17.0

There may be more issues; I haven't checked but probably all the above can be worked around very easily.

The question is: should we care?

Rust's rapid release schedule means 1.18.0 was only released in June this year while 1.15.1 is from February.

[pitdicker]

While I do not care all that much for older versions, these issues seem not that hard to work around? For something as widely used as rand it seems sensible to keep the requirements as low as possible...

[dhardy]

See: https://github.com/rust-lang-nursery/api-guidelines/issues/123

I guess our policy should simply be not to increase the minimum version unless there is good reason, and also that any change must be included in the changelog.

[pitdicker]

I did some testing. Rand 0.3.18 can build with Rust 1.9.0. After the merge of JitterRng it requires Rust 1.13.0, because of ? support.

I think we will want ? support for the error handling eventually. Does it make sense to name Rust 1.13.0 as the lowest supported version?

[dhardy]

I don't see any incentive to go back before 1.13; in fact I don't really see any to move the current minimum backward.

I checked the 0.3 branch compiles with Rust 1.14.0 but current master doesn't, for several reasons.

[dhardy]

TODO: add section to README describing a policy on this, basically just noting that CI has a pinned version and this should only be updated given significant reason (although probably better not to require a bump to the minor version).

[dhardy]

@FauxFaux mentions that Debian Stretch contains rustc 1.14.0. It would be nice to support this, I guess (although whether many other packages will is questionable).

Rustc 1.15:

• stabilised custom derive, which rand_derive uses, so that sub-crate cannot support 1.14
• name resolution was changed; this would require some extra imports ("use"); newer Rustc may be smart enough not to complain about unused imports that were previously required
• ?Sized was allowed in where clauses; this may impact some proposed changes (uncertain)

I probably won't work on this myself but if someone else makes a clean PR (little impact to readability & no extra warnings) we may be able to merge.

[dhardy]

@ignatenkobrain points out that the "log <= 0.3.8" restriction shouldn't be in Cargo.toml (see link above). Unless CI scripts can attach version restrictions externally this will require bumping the CI version to 1.16.

I should link this, to explain why log 0.3.9 requires rustc 1.16: https://github.com/rust-lang-nursery/log/issues/148

[pitdicker]

Maybe it is obvious, but where do we use log for?

[dhardy]

One "test" in lib.rs:

    #[test]
    fn test_gen_f64() {
        let mut r = thread_rng();
        let a = r.gen::<f64>();
        let b = r.gen::<f64>();
        debug!("{:?}", (a, b));
    }

So maybe we should just remove it..

[pitdicker]

Wow, all the trouble with log for that test?! :smile:.

[ignatenkobrain]

@dhardy you can do something like https://github.com/rust-num/num-bigint/blob/master/ci/rustup.sh#L10-L14

[dhardy]

Thanks @ignatenkobrain. Turns out there' s a simpler solution in any case.

[dhardy]

I'm considering updating the minimum Rustc to 1.22 for the rand v0.5 release. It's not strictly necessary but allows nicer code. See https://github.com/rust-lang-nursery/rand/pull/239

Any thoughts / objections?

[FauxFaux]

I've come to realise that trying to support old versions is currently folly; things move too fast and too many other core libraries only support current stuff. Go mad, but at least try and keep it documented?

[dhardy]

That is my conclusion too. Maybe the Rust 2018 Epoch will be stable enough to be useful in Debian 10 "Buster" but I wouldn't be surprised if not (even for a mature language like C++, targetting an LTS distro can be a nuisance).

For sure there will be a note in the changelog; maybe also the readme.