Understanding the rust 1.80 backward incompatibility

1

I want to see if I have understood the 1.80 issue that caused the time crate breakage, both the technical cause of it, but also the project management part. Actually, I'm more interested in the latter -- if I've understood it correctly, this can happen again.

The technical issue: The problem was that a type inference was unambiguous prior to 1.80, but after that std implemented something that created an ambiguity. In practical terms: One could use _ in certain places before 1.80, but after that the compiler wouldn't know which type/implementation to put in its place.

The project management issue: If the Rust project would guarantee that these things would never happen again, it would mean one of two things:

  • they would never be allowed to add new implementations to std that are currently unambiguous.
  • unambiguous type inference would need to be removed from the compiler.

.. and neither of these are acceptable/feasible, which is why it was allowed, and will be allowed in the future.

Is this the basic gist of it?

2

Well, that's the gist of it. I don't know about "will be allowed in the future". I'd much prefer if this never happened again. There are currently discussions of this issue and possible mitigations on IRLO [1][2].

3

First you have to define "these things". It probably means "crater finds more than $N broken crates" or something, for example, and not "never break any crate due to inference ever". The teams consciously make changes which are always considered major breaking changes[1] under their own definition already today, if the breakage is small enough. So it wouldn't be "never" in the first bullet.

Next, the second bullet probably isn't possible without also breaking the ecosystem. Maybe there's a middle ground...

Finally, that list isn't exhaustive; there are other possible outcomes. For example version or edition based inference; making a compatibility lint and waiting for the ecosystem to catch up...

There's more conversation in the links @afetisov provided.

  1. in contrast with breaking inference, which can be a minor breaking change ↩︎

4

IMHO:

  • inference breakage is allowed per Rust's stability RFC, so the libs team technically followed the protocol. AFAIK there are no written rules for how to introduce such breakage and how much impact is allowed, so the how part didn't get much consideration.

  • the problem has been seen as just one broken crate, which already had a fix released, so it seemed like a problem solved. The team members focused on the fact that Cargo.lock of libraries is not used, and underestimated that they use their lock file in CI, that every end user has their own Cargo.lock, and that it has widespread impact on binary crates, and significantly breaks git bisect.

  • there were similar one-big-crate breakages before (socket transmute hack), but they happened to be rolled out slower, and the ecosystem had time to upgrade before rustc broke it. This case rolled out quickly.

  • the impact was underestimated, and the relnotes tag was misunderstood/overlooked, so there was no warning about this breakage and no official communication.