3 ms·

> If it’s compatible with Rust 2018, then there’s no reason it couldn’t be in Rust 2018. Only breaking stuff needs to wait until the next edition. That sounds

> If it’s compatible with Rust 2018, then there’s no reason it couldn’t be in Rust 2018. Only breaking stuff needs to wait until the next edition. That sounds like Rust 2018 would get a new feature, something that sounds in contradiction with a feature freeze. > It’s really not clear to me what exactly you’re proposing, but it sounds like breaking syntax, and so yes, it would have to wait. I was trying to clarify things by proposing a particular situation, a non-breaking syntax change, so I'm not sure how that could possibly sound like breaking syntax. If you believe it's impossible for syntactic sugar to be introduced with backwards compatibility then how do you explain the question mark operator for Error handling?

steveklabnik 8y ago
Again, the “freeze” is for 2018 specific features, the ones that would be backwards incompatible with 2015. ? isn’t sugar, and also isn’t a breaking change.
- irishsultan 8y ago
  Okay, so is it really so difficult to contemplate even the mere possibility that there might be changes to rust that are incompatible with rust 2015, but not with rust 2018. Because that's what you seem to claim when you're saying that Rust 2018 will be feature-frozen. > ? isn’t sugar, and also isn’t a breaking change. ? is not a breaking change, but is a new feature. That's the whole point. (also it's syntactic sugar by any definition of that word that I'm familiar with, I'd be interested to hear what your definition is, but it's otherwise besides the point).
  - steveklabnik 8y ago
    Yes, it is unlikely that that’s true. At least, I can’t think of anything. Or at least, nothing that’s compatible. We do have features for 2018 that are incompatible with 2015. ? isn’t syntax sugar because it doesn’t desugar into other syntax, it’s a feature in its own right. At least, that’s what I recall. Regardless, I don’t think it really matters.
    - irishsultan 8y ago
      > Yes, it is unlikely that that’s true. It may be unlikely that such changes exist, but evidence from two different people has shown that it's at least something that can be considered (even if it's by people not familiar with Rust). > At least, I can’t think of anything. Or at least, nothing that’s compatible. Nobody asked you to come up with a che, the question was what would happen if someone did come up with such a change. The answer seems to be "it will be added" (assuming it goes through the normal process of course, I'm not claiming that a random change will be added merely because it's compatible), at that point you can no longer claim a feature freeze, because a feature freeze is a much stronger claim than merely saying "it's unlikely that there will be changes". > We do have features for 2018 that are incompatible with 2015. I'm fairly certain that everyone in this discussion understood that there are features in 2018 that are not in 2015, that's the whole point of having a separate edition.

steveklabnik 8y ago

Again, the “freeze” is for 2018 specific features, the ones that would be backwards incompatible with 2015. ? isn’t sugar, and also isn’t a breaking change.

irishsultan 8y ago
Okay, so is it really so difficult to contemplate even the mere possibility that there might be changes to rust that are incompatible with rust 2015, but not with rust 2018. Because that's what you seem to claim when you're saying that Rust 2018 will be feature-frozen. > ? isn’t sugar, and also isn’t a breaking change. ? is not a breaking change, but is a new feature. That's the whole point. (also it's syntactic sugar by any definition of that word that I'm familiar with, I'd be interested to hear what your definition is, but it's otherwise besides the point).
- steveklabnik 8y ago
  Yes, it is unlikely that that’s true. At least, I can’t think of anything. Or at least, nothing that’s compatible. We do have features for 2018 that are incompatible with 2015. ? isn’t syntax sugar because it doesn’t desugar into other syntax, it’s a feature in its own right. At least, that’s what I recall. Regardless, I don’t think it really matters.
  - irishsultan 8y ago
    > Yes, it is unlikely that that’s true. It may be unlikely that such changes exist, but evidence from two different people has shown that it's at least something that can be considered (even if it's by people not familiar with Rust). > At least, I can’t think of anything. Or at least, nothing that’s compatible. Nobody asked you to come up with a che, the question was what would happen if someone did come up with such a change. The answer seems to be "it will be added" (assuming it goes through the normal process of course, I'm not claiming that a random change will be added merely because it's compatible), at that point you can no longer claim a feature freeze, because a feature freeze is a much stronger claim than merely saying "it's unlikely that there will be changes". > We do have features for 2018 that are incompatible with 2015. I'm fairly certain that everyone in this discussion understood that there are features in 2018 that are not in 2015, that's the whole point of having a separate edition.