4 ms·

Because they haven't actually broken backwards compatibility, but rather allowed people to opt-in to incompatible changes by setting a flag.

dj-wonk 8y ago
I'd like to see more projects consider this approach for updates. Would anyone like to share other examples of this sort of thing (such as in other compilers or tools)?
- steveklabnik 8y ago
  We took a lot of inspiration from C++ and Java, both of which have some sort of flag that says “compile this against a particular version”.
  - mlindner 8y ago
    Except C++03 isn't getting any more features added to it and neither is C++11 (which also use the year, not version number). 2015 edition will continue to get new features.
    - steveklabnik 8y ago
      Yes, the non-2015 editions are direct analogues, but 2015 is special.
deathanatos 8y ago
> haven't actually broken backwards compatibility My understanding from reading the article is that they have broken backwards compatibility; things using the new keywords that were introduced (e.g., "await") will no longer compile. I think part of the confusion here is that there are essentially two things: there's the compiler, and there is the language itself. It appears (from the article) the compiler can presently support compiling either "edition 2015" or "edition 2018" of the language. (So, it's not the compiler's major we're bumping, rather, it's the language's.) That flag which says which "edition" to use could just as easily specify which SemVer major version to use. So, instead of saying "use Rust edition 2015" or "edition 2018" it would just be "Rust (the language) v1" or "Rust (the language) v2". There's no difference aside from the naming. The year doesn't particularly add anything, and obscures if we're jumping over multiple "barriers" of breaking changes or not. I'm not actually sure that that really matters. My only thought is that having completely different looking things might be better in that it just visually distinguishes the two better. I've repeatedly seen devs muddle the difference between the language, and a implementation of the language, and what the language guarantees and what the implementation happens to do.
- steveklabnik 8y ago
  You have to add in a flag to get those new changes, so it is backwards compatible. All existing code compiles and will continue to compile with no changes into the future.
  - deathanatos 8y ago
    The flag's mere existence is proof that the change is not backwards compatible. If it were, you wouldn't need the flag. > All existing code compiles and will continue to compile with no changes into the future. My point, again, is that it won't compile without changes in the new edition. "Edition" is the word that was chosen (and it's not necessarily a bad word), but what it is is a version for the language. Whenever a backwards incompatible change (or set of changes) is going to be made to the language, that's a new "edition", but you could just say "version" and it would be as accurate. Again, consider the language and compiler as separate entities, each with their own API, and I think it becomes clearer. Changes have been made to the language (e.g., the addition of new keywords) that render strings previously valid in the language now invalid, or valid with a changed meaning. In any system, this is a breaking change. This change could, were SemVer used, be identified with a major version bump.¹ That the compiler (which itself has a version number, separate from the language now) is capable of recognizing a flag and switching internally which version of the grammar it uses is great, but again, proof that there exists a version of the grammar (called "edition"). ¹But honestly, that ship has sailed for Rust. And that's fine, and I think it's just a different term, and that it has a good chance of helping better convey the meaning by simply being different. But the argument that, under that, it's essentially SemVer, is nonetheless true. (That at present the compiler and the language are very much intermixed makes this much more muddled. Were the language's definition more formal, I think this would all get much clearer, as we could ignore rustc, and talk about the language.)
    - steveklabnik 8y ago
      All existing code still compiles, just as before, with no changes. That’s backwards compatibility.
- 8y ago

dj-wonk 8y ago

I'd like to see more projects consider this approach for updates. Would anyone like to share other examples of this sort of thing (such as in other compilers or tools)?

steveklabnik 8y ago
We took a lot of inspiration from C++ and Java, both of which have some sort of flag that says “compile this against a particular version”.
- mlindner 8y ago
  Except C++03 isn't getting any more features added to it and neither is C++11 (which also use the year, not version number). 2015 edition will continue to get new features.
  - steveklabnik 8y ago
    Yes, the non-2015 editions are direct analogues, but 2015 is special.

deathanatos 8y ago

> haven't actually broken backwards compatibility My understanding from reading the article is that they have broken backwards compatibility; things using the new keywords that were introduced (e.g., "await") will no longer compile. I think part of the confusion here is that there are essentially two things: there's the compiler, and there is the language itself. It appears (from the article) the compiler can presently support compiling either "edition 2015" or "edition 2018" of the language. (So, it's not the compiler's major we're bumping, rather, it's the language's.) That flag which says which "edition" to use could just as easily specify which SemVer major version to use. So, instead of saying "use Rust edition 2015" or "edition 2018" it would just be "Rust (the language) v1" or "Rust (the language) v2". There's no difference aside from the naming. The year doesn't particularly add anything, and obscures if we're jumping over multiple "barriers" of breaking changes or not. I'm not actually sure that that really matters. My only thought is that having completely different looking things might be better in that it just visually distinguishes the two better. I've repeatedly seen devs muddle the difference between the language, and a implementation of the language, and what the language guarantees and what the implementation happens to do.

steveklabnik 8y ago
You have to add in a flag to get those new changes, so it is backwards compatible. All existing code compiles and will continue to compile with no changes into the future.
- deathanatos 8y ago
  The flag's mere existence is proof that the change is not backwards compatible. If it were, you wouldn't need the flag. > All existing code compiles and will continue to compile with no changes into the future. My point, again, is that it won't compile without changes in the new edition. "Edition" is the word that was chosen (and it's not necessarily a bad word), but what it is is a version for the language. Whenever a backwards incompatible change (or set of changes) is going to be made to the language, that's a new "edition", but you could just say "version" and it would be as accurate. Again, consider the language and compiler as separate entities, each with their own API, and I think it becomes clearer. Changes have been made to the language (e.g., the addition of new keywords) that render strings previously valid in the language now invalid, or valid with a changed meaning. In any system, this is a breaking change. This change could, were SemVer used, be identified with a major version bump.¹ That the compiler (which itself has a version number, separate from the language now) is capable of recognizing a flag and switching internally which version of the grammar it uses is great, but again, proof that there exists a version of the grammar (called "edition"). ¹But honestly, that ship has sailed for Rust. And that's fine, and I think it's just a different term, and that it has a good chance of helping better convey the meaning by simply being different. But the argument that, under that, it's essentially SemVer, is nonetheless true. (That at present the compiler and the language are very much intermixed makes this much more muddled. Were the language's definition more formal, I think this would all get much clearer, as we could ignore rustc, and talk about the language.)
  - steveklabnik 8y ago
    All existing code still compiles, just as before, with no changes. That’s backwards compatibility.
8y ago