Edition benefits
Edition benefits
Posted Feb 21, 2025 14:33 UTC (Fri) by Wol (subscriber, #4433)In reply to: Edition benefits by khim
Parent article: Rust 1.85.0 released
> It absolutely is unlocked by editions.
So you're agreeing with him? (Sorry, your English is good, but like here lets you down every now and then.)
Cheers,
Wol
Posted Feb 21, 2025 14:47 UTC (Fri)
by khim (subscriber, #9252)
[Link] (9 responses)
In this particular case it wasn't my English, but more of a typo, I suspect. Indeed, I agree with part that I cited, but I suspect it contains a typo (which I have only noticed when you have pointed it out). The whole, larger, phrase looks like this: I'm 99% sure that what @tialaramex wanted to wrote was that's something else than what was NOT unlocked technically by Editions — that's certainly how I read it till you pointed out that this pesky “not” is just simply not there… but without it the whole sentence stop making any sense. Mea culpa. Indeed as cited (and not as it looked in my head) we agree violently… but now I wonder if “A, but A” is normal for English…
Posted Feb 21, 2025 15:15 UTC (Fri)
by daroc (editor, #160859)
[Link] (1 responses)
When writing articles, I generally have to cut down on my use of "but" because it's generally less precise than spelling out the relationship between things specifically.
Posted Feb 21, 2025 15:47 UTC (Fri)
by Wol (subscriber, #4433)
[Link]
(Not helped by the fact that, in this sort of construct, "technical" often does not mean technical. I don't think it makes much difference here, though.)
Cheers,
Posted Feb 21, 2025 15:18 UTC (Fri)
by Wol (subscriber, #4433)
[Link] (1 responses)
"but that's something else than what was unlocked technically by Editions"
As I read it, it wasn't Editions themselves that made it possible, but that the existence of Editions made someone say "hey, we can deprecate the mistake without breaking existing code" - it was a complete change of thinking which wouldn't have happened without Editions, but Editions themselves weren't what made it possible.
Cheers,
Posted Feb 21, 2025 15:29 UTC (Fri)
by khim (subscriber, #9252)
[Link]
And that's exactly what I'm objecting against here: Editions made it possible in a quite literal sense. They made it possible to introduce Without editions they would have needed to have that exception “sure,
Posted Feb 21, 2025 18:22 UTC (Fri)
by tialaramex (subscriber, #21167)
[Link] (4 responses)
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.
> Sorry, your English is good, but like here lets you down every now and then.
Edition benefits
Edition benefits
Edition benefits
Wol
Edition benefits
Wol
> but Editions themselves weren't what made it possible
Edition benefits
impl IntoIterator for [T; N] without adding strange wart to the rules of the language, that normal people should care about: sure there is this “if your code uses Rust 2015 or 2018 then it wouldn't be able to see this method even if it's, actually, exists”… but that's the rule of of the “it wasn't always this simple” variety, the rules for the last version of the language are kept simple and logical.IntoIterator::into_iter exists, but you couldn't call it via short array.into_iter() form, you have to always use full IntoIterator::into_iter(array) form” would have been kept around forever, even in a new code… this would have been much harder to accept.Edition benefits
> 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