[codeflo]

Your last two paragraphs describe Rust’s process differently than I would in comparison to this suggestion.

First, significant new language features are introduced all the time, even in stable, all of them enabled by default (indeed, there’s no way to turn them off).

Nightly’s #![feature(…)] is strictly for experimental stuff that is buggy and/or will change until stable release. I’m sure you know this, but all of those are intended to be backwards compatible! I think that’s a big difference.

Incompatible changes in Rust never happen with “features” (as you know, stable doesn’t even have those), but only with “editions”. The goal of an edition is to carve out a large chunk of future design space, like introducing some keywords for planned features, or rarely, fixing really annoying inconsistencies that require a breaking change. They feel a lot more proactive (we want to do this, we need an edition) than retroactive.

[tialaramex]

Yeah, the crucial trick is that Rust is a single language but the Editions system lets people keep older syntax in source code, knowing it will be transformed into the single abstract syntax of that language.

Rust editions are not versions of the language, they're just syntax.

New features of the language in a new library or compiler version work fine in all editions unless they require syntax which isn't in your chosen edition.

Rust 2015 edition is only restricted to the syntax from 2015, all the features of today are available unless they're gated off somehow by syntax. For example the "async" keyword didn't exist in Rust 2015, so, you won't be using that from 2015 edition even today. But even though in 2015 you certainly couldn't go around evaluating u32::checked_div() in a constant, it works just fine in Rust 2015 edition today, because it's not gated by syntax.

[doomvox]

> the Editions system lets people keep older syntax in source code

Perl 'features' are lexically scoped, and could be applied in a finer-grained style, if you like. Shutting something off locally is done pretty commonly (e.g. to silence an ignorable warning).

The Perl devs have a deprecation cycle to remove mis-features, even if that breaks backwards compatibility. They don't, as far as I know, make much effort to line that up with major version changes[1], it's more a matter of making sure there's a long period of warning.

[1] The difficulty of course, was that for a long time the language now known as Raku was squatting on the next major version, "6", hence the need to jump to "7" to avoid confusion with Raku.

[marcosdumay]

In fact, it is much more similar to how people expected the Haskell's extensions to work when standardizing the language than anything from Rust.

Anyway, on practice they didn't work like that.