Decision: Use the condition name `rust_version` for RFC 2523

View all comments

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 https://github.com/rust-lang/rust/pull/141766#issuecomment-2981860440 for further discussion on this.

Note: The cfg(target_version(..)) RFC would only make this more confusing, as the word target would appear in the same line as unqualified version, inviting confusion with target_version.

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 https://github.com/rust-lang/rust/issues/64796#issuecomment-939364992. 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 https://github.com/rust-lang/rust/pull/141766#issuecomment-2968317468.

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!

Start by reading RFC 2523 and the linked RFC, issue, and pull-request discussions about the condition syntax. Compare the proposed rust_version name with version, lang_version, and rustc_version, then resolve whether the condition should support function, equality, or both forms. Done means the condition name and syntax have a settled decision.