A drawback of this approach is that using #[cfg(version(1.28))] would make libsyntax fail to parse this syntax on all pre-existing toolchains.

That is, if you have to support toolchains older than whatever toolchain version this attribute is this shipped in, you need to put the #[cfg(version(...))] behind a feature gated module like this to avoid older toolchains from trying to parse it:

// In the module where you actually want to use `#[cfg(version)]`
cfg_if! {
    if #[cfg(toolchain_supports_cfg_version)] {
        mod internal;
        use internal::*;
    }
}

// and then in a separate internal.rs file
#[cfg(version(1.42))]
struct Foo;

and then have a build.rs that detects the rust toolchain version and sets --cfg toolchain_supports_cfg_version.

and then have a build.rs that detects the rust toolchain version and sets --cfg toolchain_supports_cfg_version.

I mean, at that point, we can just implement this as a library that can be easily used from build.rs to define such config macros, which would allow the code above to just be written as:

// In the module where you actually want to use `#[cfg(version)]`
#[cfg(rust_ge_1_42_0)]
struct Foo;

Note that the following syntax does not have this problem and is IIRC backward compatible down to Rust 1.0:

#[cfg(rust_version = "1.42.0")] // in the cargo sense
struct Foo;

@gnzlbg I think everyone considering using this feature understands that it will only work going forward, in versions that support version and accessible. That"s still quite useful.

@joshtriplett when it comes to older versions, there"s a difference between "doesn"t work" and "can"t be parsed". I"d like to avoid the second situation if possible.

This does bring though the idea that whichever release version becomes stable will probably become the new minimum stable rust version that a lot of libraries will bump to. It might be good to pair it"s release with a major feature(s) so that the most amount of people can be benefit from them.

It"s probably not that difficult to support two versions; it"s mostly just a bit of parsing inside or outside the string and they"ll be uniform otherwise.

@XAMPPRocky that"s pretty clever =P will just have to find some major feature to couple with heh.

This does bring though the idea that whichever release version becomes stable will probably become the new minimum stable rust version that a lot of libraries will bump to.

At best, depending on how cfg(version) is shipped, projects might be able to just use it for detecting newer features, but it will live alongside the feature-detection code that these projects are already using. The "old" feature detection code is simple and low maintenance, so bumping the MSRV to be able to exclusively use cfg(version) is something that doesn"t add much value, while compromising something that"s important for these project: the only reason a project would do feature detection is to be able to support older toolchains, so the project must see value in that.

I think that maybe eventually all projects might be able to just use cfg(version), but that will be a consequence of them bumping the MSRV due to other issues, and not because there is a lot of value in bumping the MSRV to a toolchain that supports cfg(version).

At best, depending on how cfg(version) is shipped, projects might be able to just use it for detecting newer features

I don"t think cfg(version) has to be immediately valuable. Eventually more features will be covered under cfg(version) than those features that aren"t, and then it will be more compelling for more libraries.

so bumping the MSRV to be able to exclusively use cfg(version) is something that doesn"t add much value

Unless your MSRV is one version behind cfg(version) your value won"t be exclusively cfg(version). If your MSRV is 1.15 for example and cfg(version) was released in 1.40.0 you"d be getting everything from 1.16.0–1.40.0, and you"d be able to use cfg(version) to ease future feature development.