Edition benefits
Edition benefits
Posted Feb 21, 2025 18:22 UTC (Fri) by tialaramex (subscriber, #21167)In reply to: Edition benefits by khim
Parent article: Rust 1.85.0 released
1. Editions technically unlocks only syntax changes. You can do some obvious things by manipulating the syntax and you can do some less obvious but still practical things if you get clever. But some things are impossible.
2. This ability as a second order effect drives appetite. Instead of being told that any desired change is difficult or impossible, Editions teach Rust programmers that their language can be changed. Do they all understand what's possible and what's not? Of course they don't, leading to...
3. implementing IntoIterator for new types is something you can just do in Rust. No need for an Edition. No big deal. Except, for arrays this creates an ambiguity in existing code. Now, for an obscure type like SocketAddrV6 maybe they can just not worry. Warn the one crate using that type and carry on. But this wasn't SocketAddrV6 or even VecDeque, this was [T; N] the array type, so it's not one crate it's (I think?) thousands, maybe tens of thousands. So OK, you can't do this at all in Rust, not even in an Edition.
But there's an appetite for this change as discussed, that doesn't mean it has to be done - but it means there's a reason to spend some time figuring out whether you can hack Rust so that this works because if you can't somebody is going to have to break this to the people who thought change was possible. "Not that change".
And so Rust actually carries a hack specifically for [T; N] impl IntoIterator where that trait is hidden for that type in old editions. There is (unlike for many of these changes) a custom hack which Rust will carry indefinitely, to make this work because it was deemed valuable enough to do that work.
The hack is described in the material you linked, and probably their description is more accurate than mine. But it's a hack, this is not something that is part of Editions itself, if you were trying to sell language X on Editions and you give this as an example without explaining that er, it's a hack and not part of editions, you are lying to them.
Posted Feb 21, 2025 18:46 UTC (Fri)
by khim (subscriber, #9252)
[Link] (3 responses)
Um. That's some kind of hair splitting that I don't understand. How is this hack different from, e.g. disjoint capture in closures? Yes, similarly to how Swift carries a hack for AnyColorBox. And from what I understand the justification was kind of “normally we don't do such hacks, but if it's only for old Edition, then it's acceptable”. How is it different from any other change? Even latest version of Rust have to carry “hack” that would allow your to write simply
Posted Feb 21, 2025 23:48 UTC (Fri)
by tialaramex (subscriber, #21167)
[Link] (2 responses)
In your disjoint capture example, lets break down the capture functionality today: 1. We need to be able to capture a named variable, 2. we need to be able to capture just part of the variable, not the rest, leaving that to be moved, dropped etc. or captured by something else.
Rust 2015 and 2018 Edition code needs (1) but subsequent Rust code needs both (1) and (2). Preserving (1) isn't a hack or a special case, we still need that too, in fact most of my captures use (1) and I've rarely needed (2) even though I wrote most of my Rust after 2021 Edition was available.
For your other Rust example (dyn traits) that's even more straight forward because it's literally grammar, it's like if your friend Sarah insisted you start calling her Professor Sarah. She's not a different person, but now you say "Professor Sarah" instead of "Sarah".
When I talk about a hack, I mean there's literally Rust code which exists to hide this implementation in old editions. In rustc_hir_typeck/src/method/probe.rs there's:
if self_ty.is_array() && !method_name.span.at_least_rust_2021() {
"Oh, if we're not at least 2021 Edition, this array magically doesn't impl IntoIterator as far you're concerned"
Most of the other edition specific code in Rust is to produce friendly warnings and other diagnostics, but this code is a hack like I said.
Posted Feb 22, 2025 0:26 UTC (Sat)
by khim (subscriber, #9252)
[Link] (1 responses)
No. (1) and (2) are two entirely different things. It's impossible to express (1) in Rust 2021. There are no such operation and there are no syntax for that. That ability is simply gone. Removed. Only kept around for legacy crates. It's very much a hack and special case. Semantic is different. It's implemented differently in the compiler (there are special “unique” reference which is not mutable involved), it's really very different mode with different rules. You may pretend that your captures are using (1), but that doesn't change the fact that they not handled that way. And how is that different from the exact same hack that does an opposite and allows one to use async in Rust 2015 where it's not allowed to be in Rust 2018? Not really. Edition specific code is all like that hack. Sometimes it's elevated to the language level (e.g. there's expr_2021 to deal with macros in a backward compatible way), sometimes “the old way” is only available in crate that's specifically compiled in “old edition” mode, but it's all, pretty much, looks like that. How else could you handle that difference, if not by checking some “version” filed or some “bool” (that's enabled for one edition and disabled for the other edition)?
Posted Feb 22, 2025 19:24 UTC (Sat)
by tialaramex (subscriber, #21167)
[Link]
I don't have time or energy to perform a similar dance here.
> But it's a hack, this is not something that is part of Editions itself
Edition benefits
TraitFoo instead of dyn TraitFoo in Rust 2015 Edition… what makes one of them “depend on edition” and the other “not depend on Edition”?Edition benefits
> Rust 2015 and 2018 Edition code needs (1) but subsequent Rust code needs both (1) and (2).
Edition benefits
Edition benefits