Announcing Rust 1.93.0
51 points by itamarst
51 points by itamarst
Scanning these, the main one that excites me is <[T]>::as_array. This allows you to un-erase the size of a slice, turning it into an array of compile-time known size. I've hand-rolled this before when working with chunks_exact, but then I could only do it for one hardcoded size. The version they stabilized uses const generics, so it works for any chunk size, nice!
Why even bother with 1.? Why not Rust 93? I've found that semantic versioning for applications to be a bit silly myself.
You might as well use calver[1] then. At the very least, the numbers are meaningful.
+1 on calver. We already use years for editions, right?
It's all "just a number" in the end but well... I would like to hear the counter argument against calendar versioning for Rust. I guess the biggest is "who cares".
Editions and toolchain versions are independent of each other. Some features are part of an edition, which are introduced in a version, but an edition independent feature which works as far back as the 2015 edition can be introduced in a version. Editions are purely to gate behavior that would otherwise cause backwards compatibility break. They are not a language versioning mechanism.
I understand the difference between editions and toolchains.
I'm saying that we didn't do "Edition 2"/"Edition 3", but "Edition 20xx".
Similarly "Rust 2026.1.20" would provide useful information in a way "1.93" does not (especially in the "never 2.0" universe)
Because Rust likes semver and intends to keep backwards compatibility with code written for past 1.x versions. It does that with some caveats, but it's not nearly as wild as 93 major breaking versions.
Sorry for the tangential question but are there any plans for Rust 2.x? Rust looks widely adopted and stable so I don't think so. But I don't keep up with what is going on behind the scenes.
A Rust 2.0 would be a major departure from long-standing policy. In general, the Editions RFC was considered a “never 2.0” stance from the project.
Wouldn't a Rust 2.0 come after Rust 1.99.9 ? There would be nothing special about it. It's just the next version.
After 1.99 comes 1.100
I presume they're going for semantic versioning, and we'll see version 1.100 late this year/early next year.
Rust editions* exist to prevent the need for a 2.0. They allow the language to make backwards incompatible changes (e.g. adding new keywords) without breaking existing code that still compiles with the older edition (s).
Is this just major version changes with extra steps?
A key issue with, say, the Python 2 to 3 transition was that it bifurcated the ecosystem. Rust editions don't do that.
Well, Python is an untyped language and it executed that transition quite poorly.
Java has managed to add quite a lot to the language with only a minor pause (mostly due to Sun->Oracle takeover), and a 30 years old binary will still run without trouble.
To expand on sunshowers' comment, you can have a project on one edition that depends on crates targeting other editions (without restriction: a 2015 project can use 2024 crates, and vice versa). You could write a python library that could work on both 2 and 3, but that was an explicit choice a library had to make, and pay the cost for.
a 2015 project can use 2024 crates, and vice versa
Is this a feature of the compiler/Cargo ecosystem, or something inherit to the edition system?
Or in other words, is there anything stopping rustc from dropping support for 2015 edition rust in the future?
Inherent to the edition system.
Most things land in all editions, so dropping Rust 2015 means dropping the vast, vast majority of Rust.
No, because even within a single function every statement can come from a different Rust edition (editions are exposed as a per-crate setting, but macros can mix and match them, so the compiler tracks edition in the AST).
Editions are restricted in the kinds of changes they make, in that they must allow for a crate to go to the next edition while still operating with previous (or, for now I suppose) future editions.
Python 2/3 the biggest problem was you could not upgrade to Python 3 until your dependencies did, so large dep trees were forever stuck until the low level stuff (often the hardest to port!) got moved over.
Editions can't break everything, and still have compatibility requirements at the crate level.
Never say never, but one of the main parts of Rust's stability guarantee is that it will keep compiling all old code... forever. I.e. code that compiles fine on 1.20 should compile fine on 1.98.
A 2.0 wouldn't necessarily signal a hard break with this guarantee, but there needs to be some serious motivation of what is signaled by calling something 2.0.
code that compiles fine on 1.20 should compile fine on 1.98
With the exception for code that fails in later versions as it's been discovered to be UB / unsound (also meaning it always was).
Another exception is code with name collisions with a newly introduced item in the Rust stdlib. eg. this prints 1024 if Rust >= 1.91 and 0 otherwise:
trait MyTrait {
fn strict_pow(&self, _exp: u32) -> u64 {
0
}
}
impl MyTrait for u64 {}
fn main() {
println!("{}", 2u64.strict_pow(10));
}
(not actually a compilation error, but you get the idea.)
or when code uses use std::something::*;.
I actually didn't know that this would happen due to (I assume) new prelude additions.
To be fair I get warnings for that.
I think it's less about the prelude, and more that Rust's method resolution prefers inherent methods (e.g. u32::strict_pow) to trait methods (e.g. MyTrait::strict_pow). When Rust adds new inherent methods, they cut in line in front of trait methods that may already exist in other code bases. If the types weren't the same (e.g. say MyTrait::strict_pow took a String argument) you end up with a compilation error by upgrading Rust. Arguably better than the silent error, but not perfect back compat.
I think the intended policy is "it's ok to break semver if you could fix your code with more explicit decorations", but it does make the life of a library builder hard where Rust's minor semver breaks become your major break as you need to change your external API. Happened a lot in the early days (I recorded about ~4 Rust releases that broke compilation/functionality for my code out of the first ~10 releases, iirc (ed: 20, not 10)).