5 ms·

There is a spectrum from obvious breaking changes (removing a method), to non-obvious ones (trait methods, glob imports), and beyond (https://xkcd.com/1172/ htt

There is a spectrum from obvious breaking changes (removing a method), to non-obvious ones (trait methods, glob imports), and beyond (https://xkcd.com/1172/ https://xkcd.com/1172/) Before adding methods to a trait, they test the change against all public Rust code known to exist, to verify no breakage. Very occasionally this causes them to put plans on hold or work with downstream library authors (see: the num-traits crate) For the benefit of closed-source code, they also emit a warning before the change is made, so you have time to prepare or give feedback (https://doc.rust-lang.org/stable/nightly-rustc/rustc_lint/builtin/static.UNSTABLE_NAME_COLLISIONS.html https://doc.rust-lang.org/stable/nightly-rustc/rustc_lint/bu...) It's a perfectly reasonable policy. I'm not sure what more they could do, unless you expect them to literally never change any traits ever again and ossify the stdlib into whatever state it was in 2015 when Rust 1.0 was released. If that's what you want, pin your compiler/library versions and you can have it!

School-Cotton 4y ago
I’m fine with the current policy. What I would like them not to do is advertise “no breaking changes” as a major selling point of Rust, when that isn’t actually true.
- jmillikin 4y ago
  Where do you see the Rust team claiming they will make no breaking changes? Note: answers like "an anonymous nobody on Twitter says Rust is better than <other language> because it never breaks compatibility" get zero points.
  - School-Cotton 4y ago
    Here is Steve Klabnik, who is on the rust team (or at least used to be), claiming that code that doesn’t compile on a newer language revision “relies on unsound things”: https://news.ycombinator.com/item?id=32063749 https://news.ycombinator.com/item?id=32063749
    - jmillikin 4y ago
      That is not what Steve is claiming. The exact quote is: > > code written 5 years ago will often not compile today. > > citation needed. Yes, there's a few programs that relied on unsound > things for which this is true, but that's a relatively small part of > the overall amount of code. In other words, there are a small number of packages that were doing things outside the bounds of what the Rust change policy guarantees -- for example unintentionally relying on type-checking bugs, or unstable features accidentally stabilized, or implementing traits on a struct when the library doesn't control both of them. This does not mean that Rust code will "often" not compile. It is possible for Steve (and the public at large!) to know this, because the impact of breaking changes are measured by Crater. The alternative choice, to prevent compiler/stdlib changes from being able to break any valid program, would halt language evolution. We've seen this in languages like C and C++, where the standards bodies make a truly heroic effort to avoid breaking code, but (1) they stop being able to evolve the language, and (2) code breaks anyway because there's always someone who's skirting the edge of permitted extension.
      - School-Cotton 4y ago
        > for example unintentionally relying on type-checking bugs, or unstable features accidentally stabilized, or implementing traits on a struct when the library doesn't control both of them. One of these things is not like the other. Implementing your own traits on foreign types isn’t “unsound”, it’s an absolutely normal and reasonable thing to do. Steve specifically said “unsound”, which means something specific. He didn’t say “doing things outside the bounds of what the Rust change policy guarantees”.
        jmillikin 4y ago
        > One of these things is not like the other. Implementing your own traits > on foreign types isn’t “unsound”, it’s an absolutely normal and reasonable > thing to do. It's possible to do, and there's good reasons to do it, but you have to be extremely careful about either (1) specifying all method calls unambiguously, or (2) extensive testing for dependency upgrades. It's very similar to wildcard imports, because you're no longer in sole control of the local namespace. If you choose to let a dependency inject symbols into your local namespace, and that dependency is the standard library, then you're signing yourself up to have every toolchain upgrade be painful. Think of it as similar to naming C/C++ types with leading underscores. Yes, you could have gotten away with `typedef int _Bool;` for decades, but eventually the standard library will call that bet. > Steve specifically said “unsound”, which means something specific. He > didn’t say “doing things outside the bounds of what the Rust change > policy guarantees”. It seems like you're interpreting "unsound" in a sense similar to "violates type-safety soundness", but I don't think that's what Steve meant and it doesn't seem like a reasonable interpretation.

School-Cotton 4y ago

I’m fine with the current policy. What I would like them not to do is advertise “no breaking changes” as a major selling point of Rust, when that isn’t actually true.

jmillikin 4y ago
Where do you see the Rust team claiming they will make no breaking changes? Note: answers like "an anonymous nobody on Twitter says Rust is better than <other language> because it never breaks compatibility" get zero points.
- School-Cotton 4y ago
  Here is Steve Klabnik, who is on the rust team (or at least used to be), claiming that code that doesn’t compile on a newer language revision “relies on unsound things”: https://news.ycombinator.com/item?id=32063749 https://news.ycombinator.com/item?id=32063749
  - jmillikin 4y ago
    That is not what Steve is claiming. The exact quote is: > > code written 5 years ago will often not compile today. > > citation needed. Yes, there's a few programs that relied on unsound > things for which this is true, but that's a relatively small part of > the overall amount of code. In other words, there are a small number of packages that were doing things outside the bounds of what the Rust change policy guarantees -- for example unintentionally relying on type-checking bugs, or unstable features accidentally stabilized, or implementing traits on a struct when the library doesn't control both of them. This does not mean that Rust code will "often" not compile. It is possible for Steve (and the public at large!) to know this, because the impact of breaking changes are measured by Crater. The alternative choice, to prevent compiler/stdlib changes from being able to break any valid program, would halt language evolution. We've seen this in languages like C and C++, where the standards bodies make a truly heroic effort to avoid breaking code, but (1) they stop being able to evolve the language, and (2) code breaks anyway because there's always someone who's skirting the edge of permitted extension.
    - School-Cotton 4y ago
      > for example unintentionally relying on type-checking bugs, or unstable features accidentally stabilized, or implementing traits on a struct when the library doesn't control both of them. One of these things is not like the other. Implementing your own traits on foreign types isn’t “unsound”, it’s an absolutely normal and reasonable thing to do. Steve specifically said “unsound”, which means something specific. He didn’t say “doing things outside the bounds of what the Rust change policy guarantees”.
      - jmillikin 4y ago
        > One of these things is not like the other. Implementing your own traits > on foreign types isn’t “unsound”, it’s an absolutely normal and reasonable > thing to do. It's possible to do, and there's good reasons to do it, but you have to be extremely careful about either (1) specifying all method calls unambiguously, or (2) extensive testing for dependency upgrades. It's very similar to wildcard imports, because you're no longer in sole control of the local namespace. If you choose to let a dependency inject symbols into your local namespace, and that dependency is the standard library, then you're signing yourself up to have every toolchain upgrade be painful. Think of it as similar to naming C/C++ types with leading underscores. Yes, you could have gotten away with `typedef int _Bool;` for decades, but eventually the standard library will call that bet. > Steve specifically said “unsound”, which means something specific. He > didn’t say “doing things outside the bounds of what the Rust change > policy guarantees”. It seems like you're interpreting "unsound" in a sense similar to "violates type-safety soundness", but I don't think that's what Steve meant and it doesn't seem like a reasonable interpretation.