6 ms·

>> But just like you can add a "Rust 2015" feature after 2015, you can add a "Rust 2018" feature after 2018, right? > You cannot, no. So let's assume I think

>> But just like you can add a "Rust 2015" feature after 2015, you can add a "Rust 2018" feature after 2018, right? > You cannot, no. So let's assume I think of a new syntax which is compatible with existing Rust 2018 code, but which is syntactic sugar for async code (so not compatible with Rust 2015 code). Are you saying that this can not be added until Rust 2021 comes along? Or are you saying that you can add it but it won't be Rust 2018? If the latter is the case I think it's really confusing to call impl_header_lifetime_elision a Rust 2015 feature.

steveklabnik 8y ago
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. 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.
- irishsultan 8y ago
  > 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

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. 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.

irishsultan 8y ago
> 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.