We discussed this issue in the core team meeting today, revisiting the rationale and history. I’m going to try to document the high-level sentiments that came out, and we can continue from there.
Note also that we’ve been issuing strong deprecation warnings about this change since Rust 1.8, for over a year.
Philosophical issues
I think this is already a key point of disagreement. The stability story has always been about the compiler:
If your code compiles on Rust stable 1.0, it should compile with Rust stable 1.x with a minimum of hassle.
This is a crucial component to the success of the train/rapid release model: we want users to treat toolchain upgrades as a straightforward, frequent thing, which helps move the whole ecosystem forward, helps deprecations to work, and so on. (We will eventually want to offer some “long-term support” releases for folks who want to be more conservative, but the point still stands.) Given that desire, it’s critical that any given toolchain upgrade causes minimal hassle, and that’s the heart of our stability promise.
More broadly, Rust’s design philosophy is to take a holistic perspective: we try to avoid creating silos around std vs the language vs the compiler vs Cargo vs other tools vs the ecosystem, and instead focus on the quality of the end-to-end user experience for Rust. That’s another reason that the approach to stability extends beyond the pure “language definition” sense.
Coming from this philosophical standpoint, it’s paramount that compiler flags, Cargo.toml format, and other similar details follow the same pattern: if you can use them on the stable release channel, they will work in a stable fashion, full stop.
Practical issues
Turning to the more practical issues raised later in the thread:
This exact argument can be made about unstable language or library features as well. It is a definite downside of our stability model – we get less testing of unstable features because they are usable only on nightly. But that is an inherent aspect of what we’re trying to achieve with the stability system: if these things were easy to opt into, then de facto stability becomes a much more likely outcome, as this very thread indicates! In other words, this is a tradeoff we’ve already bought into, and it’s hard to see a compelling case as to why flags are particularly different here than being able to test out language features (which could also have build system interactions).
In terms of changing the accepted language, this is one reason that using nightly doesn’t just enable all unstable features freely – it still requires granular opt-in. Thus, it’s easy to catch and prevent any divergences.
I’m not sure what else to add here. It’s definitely a case of turning down a request that would ease a particular workflow, because of the long-term, broader impact on the ecosystem. But stability is something we’ve taken very seriously, and tried to provide a lot of clarity on, in the form of:
- If it compiles on the stable toolchain, it will continue to compile on new versions thereof, modulo minor disambiguations (like type annotations).
It’s hard to see a compelling argument to step away from this stance for flags.
