Repository navigation
Decision: Use the condition name rust_version for RFC 2523 #142651
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.
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!
Activity
tmandry commentedon Jun 17, 2025
cc @epage @m-ou-se @est31 @rust-lang/lang
rfcbot commentedon Jun 17, 2025
tmandry commentedon Jun 17, 2025
rfcbot commentedon Jun 17, 2025
traviscross commentedon Jun 18, 2025
I take for granted that we're going to want
cfg(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_versionbut thenedition(rather thanrust_edition) in the language, which is a choice I would find surprising.17 remaining items
m-ou-se commentedon Jun 21, 2025
Note that there have been discussions on accepting
feature("..")syntax too. If that happens,version("..")wouldn't look like a special operator anymore, but just the same as any other cfg flag (which tend to be about the crate itself or the platform, both of which also have a "version").epage commentedon Jun 21, 2025
The possibility of
feature()syntax keeps coming up. Is that being discussed or even just floated somewhere that I could read up on? I'd like to better understand it because (1) its hanging over this conversation and (2) on the surface it sounds like a terrible idea yet there seems to be something behind it that people are treating it as likely enough.traviscross commentedon Jun 21, 2025
@jhpratt is writing up an RFC. He had originally planned to open it after we had considered RFC 3796, but I suggested to him it would be useful for us to see this sooner, and so he's working on that.
There was discussion about it in rust-lang/rfcs#3796.
traviscross commentedon Jun 21, 2025
It would surprise me if we ended up making
cfg(option(".."))equivalent in general to whatcfg(option = "..")is now, as that would make it a breaking change to later add any new operators. I'd suspect thatcfg(op(".."))will remain special.Mostly I'm hoping that discussion around @jhpratt's RFC might give us better ideas for how to syntactically encode the idea of "the set of values for option X contains Y", and that perhaps we might come up with and write down some principles for when we want to represent something as a compiler-set configuration option versus as an operator.
joshtriplett commentedon Jun 24, 2025
I wouldn't find this surprising at all.
rust_versionat least has the rationale of avoiding ambiguity with "package version" (which would be an unlikely thing to have a conditional about, but it's at least imaginable).editionhas absolutely nothing to be confused with that would justify calling itrust_edition.Personally, I remain largely indifferent to
rust_version(...)vsversion(...)(the latter is nice for brevity but the former does seem potentially nice for use in cargo conditionals), but I do think we should useedition(...)and notrust_edition(...).traviscross commentedon Jun 25, 2025
We talked about this in lang triage today (without Niko present) without specific resolution. We have two members who are persuaded by this change, one member who is not (at least without first deciding on
=syntax), and two members who are mostly ambivalent. Nobody is planning to file blocking objections in any event.This is the odd case where we have less than a majority that's actively in support of the change. That's happened before, and it's probably an open question of whether in such cases the status quo (e.g., what we RFCed) should hold or whether we should break in favor of the sub-majority vote. Probably I'd suggest we can leave that to the judgment of the ambivalent members. Personally, I'll be happy enough in any case.
The best outcome, in these situations, has often been that we come up with some third option -- or at least a new conceptual model for one of the existing ones -- that makes the choice seem clear, consistent, and compelling to us all. Unfortunately we haven't found that yet here, but we can keep discussing it.
As a matter of how to do that, though -- including on the
=question -- I'd suggest that we set aside dedicated time for it. Trying to do the bikeshed in triage today turned out to be rather ineffective, and I think I can now better articulate the reasons for that.When we do a successful bikeshed, it's because we've set aside the time and space to commit to it. Doing it in triage adds time pressure because we want to move off of it to other things. That pressure was visibly weighing on people and on the discussion today.
jhpratt commentedon Jun 25, 2025
Please let me know when this is intended to be discussed such that I can join the call, particularly if it's a standalone discussion.
joshtriplett commentedon Oct 23, 2025
At this point, we've had multiple additional discussions on this and have ended up going in two other different directions that make this proposed FCP unlikely to be useful in its present form.
I think it'd be appropriate to cancel this for now so it isn't sitting on people's pending FCP lists, when the actual consensus-building process has been proceeding through discussion and (at the moment) RFC drafting.
Does that seem reasonable, @tmandry?