4 ms·

> You'd have to specify the newer edition for it to work. That seems to contradict this: > Most new features are edition-independent, and will be usable on ne

by rascul 8y ago

> You'd have to specify the newer edition for it to work. That seems to contradict this: > Most new features are edition-independent, and will be usable on new compilers even when an older edition is selected. I understand it's currently a moot point, I'm just trying to understand if I'm interpreting it correctly.

steveklabnik 8y ago
If it's an edition-independent feature, then it doesn't require the newer edition, so a compiler that doesn't support the new edition wouldn't have any problems. Maybe it would help to step through a strawman? Let's say that "impl Trait" didn't land last week, but lands six months from now, after the 2018 edition ships. Alice is working on a library project using the 2015 edition. She uses "impl Trait". Since it doesn't require the 2018 edition, it just works. Bob uses Alice's library, and uses a compiler that doesn't support Rust 2018. That's fine, as Alice hasn't used any 2018 specific things. That's my understanding of the scenario you're talking about. Did I get it right? The other scenario would be this: It's 2019. Alice is working on a library project using the 2015 edition. She tries to use the "catch" keyword, which requires edition 2018. When she tries to use it, her code will fail to compile. She has two choices: 1. not use the feature 2. update to edition 2018. If she chooses the latter, when Bob tries to use her library later, but his compiler doesn't support the 2018 edition, it will fail to compile. This is basically all of the usual backwards and forwards compatibility stuff, even without editions. If you try to use ? on a 1.0 version of rustc, your code won't compile, as that was added much later.
- rascul 8y ago
  Thank you for the explanation, I believe I understand it now. I had originally interpreted that in a manner to assume that all new features would be tagged with an edition but would be usable on older editions if the compiler supported the feature, but with your explanation I realized that my interpretation of "edition-independent" was off the mark.
  - steveklabnik 8y ago
    Great! Glad to get it sorted. That's a totally reasonable interpretation; we had to debate if that's the way we wanted to do it, or not. In the end, it seemed to mostly add complexity to remove features from people, and that seems like a bad tradeoff.

by rascul 8y ago

steveklabnik 8y ago

If it's an edition-independent feature, then it doesn't require the newer edition, so a compiler that doesn't support the new edition wouldn't have any problems. Maybe it would help to step through a strawman? Let's say that "impl Trait" didn't land last week, but lands six months from now, after the 2018 edition ships. Alice is working on a library project using the 2015 edition. She uses "impl Trait". Since it doesn't require the 2018 edition, it just works. Bob uses Alice's library, and uses a compiler that doesn't support Rust 2018. That's fine, as Alice hasn't used any 2018 specific things. That's my understanding of the scenario you're talking about. Did I get it right? The other scenario would be this: It's 2019. Alice is working on a library project using the 2015 edition. She tries to use the "catch" keyword, which requires edition 2018. When she tries to use it, her code will fail to compile. She has two choices: 1. not use the feature 2. update to edition 2018. If she chooses the latter, when Bob tries to use her library later, but his compiler doesn't support the 2018 edition, it will fail to compile. This is basically all of the usual backwards and forwards compatibility stuff, even without editions. If you try to use ? on a 1.0 version of rustc, your code won't compile, as that was added much later.

rascul 8y ago
Thank you for the explanation, I believe I understand it now. I had originally interpreted that in a manner to assume that all new features would be tagged with an edition but would be usable on older editions if the compiler supported the feature, but with your explanation I realized that my interpretation of "edition-independent" was off the mark.
- steveklabnik 8y ago
  Great! Glad to get it sorted. That's a totally reasonable interpretation; we had to debate if that's the way we wanted to do it, or not. In the end, it seemed to mostly add complexity to remove features from people, and that seems like a bad tradeoff.