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

[tmandry]

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.

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 #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!

[tmandry]

cc @epage @m-ou-se @est31 @rust-lang/lang

[rfcbot]

Team member @tmandry has proposed to merge this. The next step is review by the rest of the tagged team members:

• @joshtriplett
• @nikomatsakis
• @scottmcm
• @tmandry
• @traviscross

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
See this document for info about what commands tagged team members can give me.

[tmandry]

Actually that feels a bit presumptuous; I'll leave at least a little time for discussion before kicking off FCP.

@rfcbot fcp cancel

[rfcbot]

@tmandry proposal cancelled.

[traviscross]

I take for granted that we're going to wantcfg(edition("..")) as well, however spelled, and so I'd like for us to settle these both together.

In particular, as noted, this suggests that we're going to need to break from Cargo's choices on one or the other unless we were willing to do rust_version but then edition (rather than rust_edition) in the language, which is a choice I would find surprising.