Need a mechanism to write rust-version-specific code

[erickt]

Since rust is still going through active development, it's hard to write a library that works for both rust-0.4 and rust-incoming. We need a cfg #[cfg(rust_version="0.5")] to carve off chunks of code that have evolved in between versions.

If we want to get more fancy with these controls, I do have an old semantic version parser I wrote back in the 0.3 days. Maybe we could use something like that to let us write checks like:

#[cfg(rust_version=">=0.4-beta")]
#[cfg(rust_version="<=0.4")]
fn foo() { ... }

#[cfg(rust_version=">0.5")]
fn foo() { ... }

[catamorphism]

Nominating for maturity milestone 3 (feature-complete).

[graydon]

I'd suggest it's more of a backwards-compatibility issue, figuring out how we wall off version incompatibility.

[steveklabnik]

This kind of thing is really useful for the RubySpec project. I don't think people will be building an alternate Rust any time soon, but it's also more comprehensive than the standard distribution's unit tests as well.

Anyway. Just pointing it out since Rust is trying to learn so much from other languages.

[graydon]

accepted for feature-complete milestone

[cmr]

Still relevant. Note we have semver support in extra::semver now.

[cmr]

To implement this one just needs to, during cfg-stripping, compare any given rust_version to the current version.

[pnkfelix]

Accepted for 1.0, assigning P-backcompat-lang.

[flaper87]

cc #3392

[kaseyc]

I have a working version of this, using the syntax given in the initial post, though it requires proper semantic versioning to run (#11396, #13289).

[brson]

What do we need to do to get this moving again?

This should probably take into account #3392, which calls for version markers at the top of source files. That issue may be covered simply by putting the tags described herein at the top of crate files.

[kaseyc]

Someone needs to come up with a way to integrate this and put it in an RFC. It seems that trying to implement it in the current cfg system is not a particularly good solution for a number of reasons, one of the main ones being the cfg! macro.

As for #3392, implementing this issue and using top level #! attributes seems like it could work, though it wouldn't solve the problem of older parsers that don't have it implemented (if it is a problem). I know @eddyb said in IRC that he had an idea for this issue.

[cmr]

We don't need to support anything older than whatever we release as 1.0, so
depending on current syntax is fine.

On Wed, Jun 11, 2014 at 5:43 PM, Kasey Carrothers notifications@github.com
wrote:

Someone needs to come up with a way to integrate this and put it in an
RFC. It seems that trying to implement it in the current cfg system is
not a particularly good solution for a number of reasons, one of the main
ones being the cfg! macro.

As for #3392 #3392, implementing
this issue and using top level #! attributes seems like it could work,
though it wouldn't solve the problem of older parsers that don't have it
implemented (if it is a problem). I know @eddyb https://github.com/eddyb
said in IRC that he had an idea for this issue.

—
Reply to this email directly or view it on GitHub
#3795 (comment).

http://octayn.net/

[cmr]

(I agree that doing anything on less than per-crate granularity is the path to madness)

[pcwalton]

Nominating for removing from milestone because I don't believe this is backwards incompatible.

[brson]

P-low, not 1.0.

[brson]

A potential way to solve some of these use cases without impacting the language is to have cargo inject cfg variables related to crate versions (and remember a version of std is the same as the language version), e.g.:

#[cfg(crate(core(version == "1.0")))]
mod stuff = "stuff-1.0";

#[cfg(crate(core(version == "1.1")))]
mod stuff = "stuff-1.1";

It's very likely we can keep the language around crate files backwards compatible forever, so using something like this at the crate level could smooth over not just lib issues, but lang as well.

[steveklabnik]

I'm pulling a massive triage effort to get us ready for 1.0. As part of this, I'm moving stuff that's wishlist-like to the RFCs repo, as that's where major new things should get discussed/prioritized.

This issue has been moved to the RFCs repo: rust-lang/rfcs#700