[steveklabnik]

1. Depends on the new project, of course. Just like any language.

2. Same thing. You can construct an example that breaks any language in existence.

3. Yes.

4. Yes.

5. Yes.

6. You’re using an idiosyncratic definition, so yes, it’s not the same. Backwards compatibility is about the same thing continuing to compile, not about changing things and expecting it to still compile; that’s forwards compatibility.

[phaylon]

Once again something is at odds here. You give resounding "Yes" comments, but in the backwards compatibility discussions I had with language team members, those "Yes" comments were actually "not really our problem" answers.

I also don't know how current code running in a future compiler is forward-compatibility. And the Rust guarantee only kind-of holds if you define "code" as "crate". Everything outside of or crossing that boundary is not compatible.

To clarify and bring it to an example: Are you guaranteeing that `(a<b, c>(d))` will always be parsed as a tuple with two comparisons? Because if so I believe you're the only one.

[mlindner]

When he says "version" he means "version". Are you taking "version" to mean "edition"? No matter how many version upgrades the rust compiler gets it will still compile 2015 edition (and 2018 edition) code.

[phaylon]

An edition is just another word for version. If the language were truly backwards compatible, you wouldn't have to tell tools like `rustc` which version/edition your code is written in.