4 ms·

I'm probably mixing different things up, but I thought the non-lexical lifetime changes made the borrow checker more permissive in the sense that some code that

• kibwen 4y ago
  The new borrow checker both allows more to compile (by being more precise about tracking control flow, allowing it to prove more advanced things about lifetime usage) and also less code to compile (again, by being more precise about tracking control flow, allowing bugs in the old borrow checker to be fixed (see https://github.com/rust-lang/rust/issues?q=is%3Aissue+label%3ANLL-fixed-by-NLL+is%3Aclosed https://github.com/rust-lang/rust/issues?q=is%3Aissue+label%... for examples)). The edition compatibility story here is interesting. When the 2018 edition came out, the new borrow checker was only turned on for code on the 2018 edition. Meanwhile, in the 2015 edition, it would run both borrow checkers and yield a warning if your code passed the old borrow checker but not the new one. After a migration period, the new borrow checker was eventually made the default on the 2015 edition as well. Because of the aforementioned soundness bugs fixed by the new borrow checker, this was seen as acceptable (soundness fixes are explicitly allowed by the stability policy, although the Rust developers still try to provide migration periods to make them less painful).
• kam 4y ago
  Editions only guarantee that old code builds with new compilers, not vice versa. New features are added to all editions unless they require e.g. new keywords that are available only in new editions.
  • pavon 4y ago
    Ah, that is right. I apologize, I think I've learned that three times now, but for some reason my brain refuses to accept it. I like that previous editions get new features when possible, unlike say C++, but I wish they'd gone with semantic versioning for the language version, like python did when both 2 and 3 were active. Oh well, I just need to remember that the edition is like the major version, and compiler version is sort of like minor version, and both are needed to specify forwards compatibility.
    • brundolf 4y ago
      I'm not sure semver would really do it here, because then you could have say: 2.17 1.17 What would you call the compiler binary that could compile both language v1 and language v2, with (shared) minor-version .17? The issue is that semantic versions are a hierarchy, whereas Rust edition x compiler version are a matrix
    • game-of-throws 4y ago
      It might make more sense to think of editions as optional changes to the surface syntax, and nothing more. They are not nearly as important as the name makes them sound.
      • brundolf 4y ago
        They are often small, but it's a mistake to say they're surface-level. Changes to syntax or semantics only get made when absolutely necessary to allow for essential features or fixes.
• game-of-throws 4y ago
  Editions are orthogonal to compiler versions. It is perfectly fine if code builds with a new compiler but not an old one. Another example of this: you can write code in a 2015 edition crate that calls the new `std::thread::scope` function.
• Macha 4y ago
  Editions promise old code works with new compilers. They do not promise new code works with old compilers
• deleted 4y ago
  [deleted]