editions

If you say all our code is Rust 2021 Edition, nobody needs to know anything that is gone in 2021 edition, and yet they also needn't learn anything that's new only in 2024 Edition (but they do still need to learn things that are new in that period but aren't part of the edition, they're just new).

In principle somebody maintaining 2015 Edition code ought to know Box<Goose> in that code might mean what we'd write today as Box<dyn Goose>. You can't do that in a modern edition, but in 2015 that's how people would have spelled that type and they were used to it.

Likewise your 2021 Edition code knows arrays are IntoIterator -- everybody (with a modern Rust compiler) can iterate over arrays of course, but in 2018 or 2015 edition code pretends to have no idea why that works so as to ensure compatibility with another old-timey thing people used to write back when arrays really weren't IntoIterator but references to the whole array as a slice were.

In practice what I'd expect is that FreeBSD would want a MSRV promise for this work. Maybe FreeBSD 14.1 promises Rust 1.79, while FreeBSD 14.0 says only Rust 1.70. People writing tools for such a system would judge whether they should be conservative (which might mean a lot more work) or not.

On the whole though, I see in this conversation something I see a lot in discussions with C++ programmers where they seem to imagine Rust's frequent release schedule means everything is in flux for the language, while at the same time considering C++'s lack of stability to be inconsequential. I notice that a no point does the discussion mention _which_ C++ language is in FreeBSD's base system. C++ 98? C++ 14? C++ 23? "Whatever Clang does -shrug-" ?

C++ ships new language versions every three years. Although in practice these languages are very similar as desired by the users, there actually is no formal promise of such commonality, and particularly on large codebases where people might value stability over a long span of time despite complex software C++ just doesn't always meet that expectation - it didn't promise to so no promise was broken.

Herb Sutter for example is proud of adding the <=> "spaceship" operator to C++ 20. This operator serves a similar purpose to Rust's PartialOrd trait. You implement it once, you get all the comparison operators at once, they're guaranteed consistent, that's a win for new C++ software. But of course there *was* already C++ code out there which had weird definitions of existing comparison operators and some of that code "broke" in the new C++ language either because of Herb's feature or because of knock-on effects in the stdlib. Maybe the code was already technically wrong (most C++ is) but for its owners the situation is that C++ 20 broke it.