This seems preferable to the current situation: I released a version of my library that uses features that are only in Rust 1.17, but the errors that people get when they compile my crate with earlier versions are cryptic and it's far from obvious that the solution is to upgrade the rust toolchain.
For this reason, maybe it would be better that this mechanism isn't used just for breaking changes, but is instead made available for all features. That is, when a feature is stabilized, don't remove the #[feature] flag for it.
Ah right. This is the cricuial reason why we need versions not years: itâs important to track a minimum version whether or not that minimum version is a breaking chance from what came before. If we track breaking and non-breaking versions alike, well, we might as well use semver as we do already.
As I mentioned in a comment on the cargo schema RFC, I think that epochs and version numbers are two distinct things. That is, you may want to upgrade to a specific rust version number because of a bug fix, or to get access to some library routines. You may do this even though your code is still "old epoch" code.
In other words, it is not just a "marketing gimmick" (as you suggested earlier) to mark an epoch separately from a release number -- there is a real technical distinction being drawn here. The rust compiler is still in the 1.X release because older code works just fine, without changes. If we called the new epoch 2.X, it might lead you to think that you cannot upgrade your compiler to Rust 2.1 just because you haven't converted your library to the new epoch yet (but that would not be true).
(Nonetheless, you could imagine using version numbers for both the rustc release and epochs. For example, iirc, Java's compiler allows you to compiler older code with a --version flag (e.g., if you use enum as an identifier, you would compile with --version 1.4 or something). There would still be two distinct concepts, presumably, but both would be versioned with a semver: the compiler in use and the "compile as of" version. The concern here is that this will give the impression of incompatibility where none exists; I am not sure if this is true or not!)
Right I was proposing something like your last paragraph. Certainly compiler version and surface langauge version can be distinguishedâIâm arguing in that last post that the language version badly needs the richer compatability partial order that semver offers. (Ironically rustc, if we never break stable CLI or drop support for old versions of the langauge, doesnât, but semver and the ever-present leading 1 donât hurt.)
To me, since we already say âRust 1.xâ, not ârustc 1.xâ the current version is felt to primarily denote the version of the langauge, and only secondarily the version of the tools. So it seems to me we already have epochs, and a new version should instead be forking off a separate compiler version.
Now, insofar that the compiler version is uninteresting because it induces a trivial compatability partial order, and the teams expressed a preference for fewer versions, one could just not bother with a seperate compiler versionâcall it ârustc for Rust 1âx.yâ or something. Basically this a choice between pruning useless but valid extra information and countering âRust 2â FUD. Iâm happy either way.
Iâd also like to add to @carols10cents explanations that the epoch-concept might severely hamper the development of competing compilers, as these may have to implement multiple language versions for ecosystem compatibility.