Description
RFC 2523 did not resolve the question of the exact syntax that should be used. We need to settle on that syntax before we can stabilize the "version" piece.
This issue proposes using the string rust_version as the name of the condition.
Rationale
There are a few reasons to pick rust_version, but the most important reason is that it is clear and unambiguous. The bare word "version" can be applied to many things, including the current crate version or other crate versions. Seeing that this is the Rust version removes that ambiguity.
Whatever key we choose, it will appear not only in Rust code but also in Cargo manifests, so we should be careful to pick a name that will mean the same thing in different contexts. (As a secondary benefit, it aligns with the Cargo.toml key used to specify a minimum supported Rust version (MSRV), rust-version.)
Note that this does not fully resolve the syntax question; there is a further question of whether to support #[cfg(rust_version(".."))], #[cfg(rust_version = "..")], or both. rust_version has the additional benefit (over version) of allowing us to support a forward-compatible syntax that isn't an immediate error on old Rust versions. But I think we can consider the questions separately.
Alternatives
version
As mentioned above, this is ambiguous, not only in Rust code but especially in contexts like Cargo.toml where the same syntax will be used. Consider for example the following; how would a user be expected to know what version refers to in this context?
[target.'cfg(not(version("1.85.0"))'.dependencies]
my_polyfill = "1.0.1"See #141766 (comment) for further discussion on this.
Any use of #[cfg(version)] is an immediate error in all existing stable versions of Rust. This means picking version would prevent us from choosing to support syntax like #[cfg(version = "..")] that old versions of Rust are forwards-compatible with.
lang_version
This was discussed some in the original RFC thread, starting around #64796 (comment). Most of the discussion revolves around whether the use of the word "rust" would violate trademarks, or whether it makes sense to use the generic term "lang" to allow for a fork. The trademark question has been clarified; uses that "allow compatibility with the Rust programming language" are explicitly approved. A rebuttal to the point about language forks is available in #141766 (comment).
rustc_version
This was also discussed in the original RFC. There are a few reasons not to choose rustc_version over rust_version:
- It will be included in the language reference. Any implementation of the language that follows the reference will therefore need to implement it, not just
rustc. - In a world where there is only one Rust implementation, it creates confusion about whether this condition would be supported by future alternative implementations.
- In a world where there are multiple Rust implementations, it would encourage an ecosystem that uses vendor-specific extensions rather than aligning on a single language definition.
- It will be used to gate language and standard library features, which we consider as separate from compiler features. The primary "compiler feature" from this point of view is "which version of Rust does it support".
And of course, it is one character longer!