Comment by ColinDabritz | Hacker News Reader

Comment by ColinDabritz | Hacker News Reader

Parent Full thread

I believe this refers to the difference between pre 1.0 churn as the language was being initially designed, and post 1.0 stability. Before, existing code was frequently broken by new changes as the language evolved. Now you should generally expect to see any current code run on any future 1.x versions without issue, and probably in all future versions. If any new language constructs are added in future, they should typically be backwards compatible, only extending the old system, rather than making changes. It's possible at some point they will be compelled to break something to fix a serious flaw or issue. For Rust, I'd have to imagine this would be safety based. As language designers they will try hard not to, and it would be a major version change, such as 2.0.

Python has had a lot of challenges with their changes from 2.x to 3.x, even though the language seems clearly improved. Much of the problem is converting popular existing libraries, which rely on a lot of donated time and effort. The Rust community is hoping to keep from being in a similar situation if at all possible.

See "What does it mean for Rust to be 1.0" in the release announcement: http://blog.rust-lang.org/2015/05/15/Rust-1.0.html

Stability Guarantee: http://blog.rust-lang.org/2014/10/30/Stability.html

Though, I want to make clear that it is permissible for some theoretical code to stop compiling when going from 1.4 to 1.5, for example. Check out https://github.com/nikomatsakis/rfcs/blob/projection-and-lif..., for an example of this.

This is because the compiler wasn't checking some cases strictly enough, and you could "hide" constraints from the compiler, causing them to fail to be enforced.

They checked against crates.io when raising this RFC, and found that there were 35 crates (packages) that would be able to keep compiling if this turned into a future-compat warning, to become an error in the release afterwards.

The example

    trait Test {
        fn test(&self) -> Option<Self>;
        //                ~~~~~~~~~~~~
        //            Incorrectly permitted before.
    }

Should be

    trait Test: Sized {
        fn test(&self) -> Option<Self>;
    }

Because `Option<T>` requires that `T` be `Sized`. Poking around on 1.3, I think that it would be an error to instantiate this trait with a [i8] or something that was not sized anyways, so you're not losing much by needing to declare the trait properly.

To elaborate, Rust has a category of bugs called "soundness bugs" which are allowed to justify breaking backwards compatibility, though the team still endeavors to make breakage as minimal and painless as possible. The Rust developers have written a tool called Crater to gauge the impact of any potential change to the compiler, which is actually really neat: it compiles nightly versions of the compiler against every package on crates.io (the central third-party package repository) and generates a report of any packages that fail to compile due to changes to the compiler.

To answer the question of why they don't bump the major version when soundness fixes break backcompat, it's because soundness bugs generally have implications for memory safety/undefined behavior, and it's assumed that people using Rust would prefer unsound code to break rather than to continue being potentially unsafe. Also, thanks to Crater, the Rust developers generally take it upon themselves to file patches with third-party crates to update them such that the package developers themselves are (ideally) neither blindsided nor inconvenienced.

Neat! That's very good handling of "as intended". Being explicit about it, having a warning phase, then moving to "more correct" to match the intent, and missed edge cases.

Reply on news.ycombinator.com