undefined | Better HN

0 pointsadastra229mo ago0 comments

As the response to that comment points out, you are confusing editions for ABI changes. Different editions are purely a source-level change in the language. All editions are ABI-compatible.

0 comments

pjmlp9mo ago

Not really, because one thing that apparently I haven't gotten across is that they don't cover semantic changes, only grammar ones for the most part.

What is the compiler supposed to generate if code from edition X calls code in edition X + 10, with a lambda written in X + 5, expecting using a specific language construct that has changed semantics across editions, maybe even more than once?

Everything compiling from source, same compiler.

Expurple9mo ago

> one thing that apparently I haven't gotten across is that they don't cover semantic changes, only grammar ones for the most part.

You have gotten it across just fine.

We're trying to get across that no one is ever going to do "global" incompatible semantic changes in editions. That's been understood from the start. Exactly because of the problems that you describe.

Although, it's still possible to "sneak in" surprisingly useful semantic changes if they are local to the function body: https://doc.rust-lang.org/stable/edition-guide/rust-2024/tem...

adastra22OP9mo ago

It would work as intended? I’m not sure what problem you are trying to point out. The lambda would compile in the edition in which it is written, resulting in a code unit passed to the other crate(s). As mentioned, the ABI is stable across editions. To put in your words, there are no semantic changes to the ABI across editions.

j / k navigate · click thread line to collapse