RFC: Rust language version attribute

[DanielKeep]

Rendered view.

This RFC proposes adding a #![rust_ver="..."] attribute and --rust-ver compiler flag.

In short, this has a few goals:

• Giving users clearer, more accurate information when attempting to compile code that is unsupported by their current compiler.
• Giving the package ecosystem a formal way of dealing with language version dependencies.
• Smoothing the transition to a future, backward-incompatible release of the language.

[lee-b]

Eh, I can't imagine every language user taking the time to research and add this attribute in all code / build scripts. I think the compiler should be able to recognise old syntax, know when it was deprecated, and inform the user of exactly which compiler version they need to compile it (at the very least; I'd prefer the compiler to retain the ability to compile older code, much like C compilers do).

[DanielKeep]

@lee-b There are two issues with "just keep parsing it". First, this means that Rust has to forever parse all code that was valid at any point previously. I concede that this isn't likely to be an issue any time soon. Secondly, it means that changing the meaning of code is incredibly dangerous. Worse, that's something you can't really detect. You've ignored the problem of people trying to compile new code with an old compiler; the compiler can't parse syntax that doesn't exist yet. Again, this is something that will only become a problem slowly over time, so I realise it's not a hugely compelling argument.

Also, users don't have to apply this to every piece of code and build script they write. The default is that if a user doesn't specify a language version, the compiler assumes they meant the newest version. The RFC only suggests that it be strongly requested or demanded by the packaging system, at which point it can just tell the user what they need to add.

As for compiling old code, that's also part of why I'm suggesting this. If a Rust 2.0 ever comes along (and let's face it, not everything is going to be perfect in 1.0), this opens the door to simply having multiple Rust compilers installed side-by-side, with the language version being used to decide which one to use on a given crate. I want to see Rust in a position where it can drop old syntax in a clean fashion, without creating huge problems like Python 3.0 did. The alternative of living with past mistakes forever doesn't strike me as particularly appealing.

[mrmonday]

I think it's important to make a distinction between Rust version (ie. the spec) and compiler version (ie. rustc). I believe both should be exposed, not necessarily in the language though. Eg. C/C++ have --std to specify the language version (and a corresponding macro), and various bits of compiler specific macros to handle the compiler version.

It's also worth questioning whether we want differences in language to be handled this way - it could quickly become a mess of #![...] as libraries try and support 50 different versions of Rust to varying levels of success. I can't find a source right now, I'm fairly sure that clang advocates feature gates over version checks though.

[DanielKeep]

@mrmonday I disagree; I think code should, as much as possible, be self-describing. Obviously, there are practical reasons to have other approaches available, but I think it's very valuable to be able to put things like the language version in the code directly. Otherwise, you end up with comments near the top of the file to the effect of "Must be compiled with --std=c++11"; you might as well tell the compiler directly instead of giving someone compiling the code another hoop to jump through.

Really, though, having it in the code benefits things like loose code examples, tutorials, and the like. Bits of code that will float around the internet forever. I mean, I've seen a few people on IRC, confused by out-of-date code examples that didn't bother to specify what version of Rust they were for. Having this be at least semi-enforceable by the compiler would be valuable.

I also agree that having (internally) fragmented code would be very much less than ideal. Jurily's suggestion (linked in Alternatives) sounds like what you describe. In which case, this RFC is basically the first step in that. That being said, I personally wouldn't expect a huge amount of that. Maybe some really big libraries might do it, but most, I suspect, will just upgrade their package's language version when needed, and people using older compilers will stick to older package versions (or possibly a fork).

[viperscape]

I think this should be stated in cargo not in rust code, as well the dependencies you pull in should optionally be versioned in cargo

[steveklabnik]

I think this should be stated in cargo not in rust code, as well the dependencies you pull in should optionally be versioned in cargo

👍

[medlefsen]

I love the idea of language version flags. One advantage, as mentioned by others, is removing the need to specify it on the command line, which feels weird when it's the developer that knows best what language version they are using.

The big win though, in my opinion, is the power it gives to the language designers to change the language as time goes on. Without per-library language versioning you end up in a situation where developers can't update their code until their dependencies are updated, which can slow the update process to a crawl (see Python 3). To avoid this language designers bolt on new features in ways that don't break old code but also complicate the language. C++ suffers from this to an extreme (For example, string literals still evaluate to C strings in C++ despite being essentially deprecated).

With versioning the designers can choose to be more aggressive with changes by gating them in the compiler with a minimum version and doing it on a per module/crate level. They can make a large breaking change to the language by trading off more complexity in the compiler (possibly just temporarily while people upgrade) for less complexity in the language. Perl is the only popular language that I know of that does this and it works great in my experience.

[rohitjoshi]

@medlefsen I agree with you.

[pythonesque]

Language versioning is a quick way to make sure that you always have an out--you are never "trapped" into a bad decision. While I understand that versioning is not the best way to upgrade most of the time, it's an amazing option to have available as a last resort. So I definitely support adding it to Rust.

[chris-morgan]

If this were to come in, I would want it to be rust_version, not rust_ver.

[Valloric]

Like others have said, this is a good idea to have so Rust doesn't lock itself into bad decisions. It should also make it easier to transition to a newer, breaking version in newer project source files while keeping the old source files compiling. A theoretical future rustc could compile both v1 and v2 source files (of one crate) depending on the attribute in the file.

[ghost]

+1 C++ went for forever backwards compatibility, and now the best practices are so ugly, Rust exists. We shouldn't make that mistake in the age of git.

Intended language version is fundamental information for any program, and should be represented in the source. Having it outside the source does not make sense in any case: either it will compile with whatever you throw at it, in which case there's no need to specify it in the first place, or it won't and passing bad --std flags is a pointless source of errors.

[alexcrichton]

@DanielKeep, thank you for taking the time to write this up, I know I certainly enjoyed reading it!

Over time we've ended up actually moving as many version-related features out of the compiler. For example the compiler used to support direct versioning of crates themselves, but the support for this was never fully realized, it was a bit hazy at times how it would be done, and adding full support would bring in a lot of extra code to the compiler that wasn't quite justified. What I'm getting at is that we've removed as much versioning support as possible and placed the burden onto Cargo instead. To this end, I agree with @steveklabnik and @viperscape that anything related to versioning likely belongs in Cargo, not in the compiler.

I do think that we will need a solution to a changing language in time, but it may also be somewhat premature to select a solution now without a problem. Some example questions which come to mind from this proposal are:

• If we add a feature in Rust 1.5, and then remove it in 2.0, how would I target a module to compiling the feature only in that range? This sort of scheme for "version requirements" is very similar to what Cargo does.
• Handling #[cfg] in the parser is fairly nontrivial and would require some semantic reorganization (and lots of manual reorganization) in the compiler.
• I think it may be safe to assume that the majority of Rust programmers will not be tagging code with #![rust_ver] when 1.0 is released. At that time we also won't have any new introduced features or any breaking changes. In theory the first time #![rust_ver] attribute is relevant (and maybe widely used) is once Rust 1.1 comes out (or perhaps soon before) if at all. This does mean that it may be ok to bide our time and reconsider this problem after 1.0.

In general, I believe that we can postpone this proposal for reconsideration after 1.0. There is precedent (or so I am told) of languages adding this form of versioning support after-the-fact rather than having it out of the gate.

For that reason, I'm going to close this as postponed, but I would like to thank you again for the very well written RFC, it was a pleasure to read!

[alexcrichton]

We also like to create tracking issues for postponed PRs, and I think that #303 may be an appropriate tracking issue for this RFC.