8 ms·
> We can’t get rid of it because we have a commitment to not breaking users’ code. This is not really true though. The commitment is about publicly visible and
by phaylon 7y ago
> We can’t get rid of it because we have a commitment to not breaking users’ code.
This is not really true though. The commitment is about publicly visible and crater-testable code. If you have your own code in-house, there isn't much guarantee unless all syntax/code you use is widely used in public as well. A known change in language grammar will be evaluated on its publicly visible impact, not on its general breakiness.
It's really disappointing to keep reading about guaranteed backwards-compatibility and then being told in RFC discussions that those don't exist.
- steveklabnik 7y agoThat’s not true. We have rules. some of those rules allow us to make changes based on that kind of thing, but it’s still done relatively little.
- phaylon 7y agoI've had many discussions and much pain about this topic. Can you tell me what I wrote that was specifically wrong? If backwards compatibility is guaranteed, turbofish cannot be "fixed". I can't find the link currently, but from my reddit post on this discussion the crucial quote from a language team member was: > Our bar for doing backwards compatibility breaks has never been soundness fixes. We have in the past done changes given future-compatibility warning with lints and then made such changes without an edition. The turbofish discussion also contains this quote: > This RFC technically amounts to a backwards incompatible change without using the edition mechanism. However, as the RFC notes, a crater run was made and the syntax was not encountered at all.
- steveklabnik 7y agoYes, there are some lang team members that want to change this policy, but it is not the current policy. Those changes were for soundness fixes. You can see how controversial that RFC was, and for that exact reason.
- phaylon 7y agoNo, that wasn't for soundness fixes. This is from the discussion surrounding syntax changes like turbofish or chained if-let bindings. Can you point me towards an authoritative post in the turbofish discussion that says that it can't happen because of backwards-compatibility changes? Because before it was locked it seemed that the language team wanted to go ahead. I've been repeatedly told by language team members that the policy you're promising people doesn't exist. I would really appreciate it if there was further clarification.
- steveklabnik 7y agoThose things didn’t happen yet. I’m talking about the ones that did happen. My understanding is that, again, some lang team members want a different policy. That doesn’t mean that it’s actually different.
- phaylon 7y agoWhere do you get that understanding? All the comments and the summaries I've seen by language team members on this give me a different impression. See this comment from Niko for example: https://github.com/rust-lang/rust/issues/53668#issuecomment-423319580 https://github.com/rust-lang/rust/issues/53668#issuecomment-... So, can you point me to a comment that tells me that the policy still holds and is as you are presenting it?
- steveklabnik 7y agoThe language evolution RFC.
- phaylon 7y agoHow do you square your interpretation with the comment I linked to above?
- nox_ 7y agoCf. `try` becoming a keyword, when there are hundreds of calls to a method named `try` in Servo, one of the largest Rust projects in existence.
- steveklabnik 7y agoHowever, none of that affects a crate until it opts into the new syntax. So everything keeps building just fine.