5 ms·

Ok so 2015 gets features added to it or would this instead be the 2018 edition?

steveklabnik 8y ago
Everything goes in 2015 unless it would need to be backwards incompatible. Other editions, like 2018, have their feature sets frozen upon release. (Though there can be small details here; for example, at launch, 2018 will have the async keyword reserved but not implemented, the implementation will come later.)
- Dylan16807 8y ago
  So 2015 and 2018 are going to have mutually incompatible features at some point in the future? If 2015 is the only one that won't be generally feature-frozen, it really should have had a different-looking name. Edit: That blog post says "We’ll continue to add features to Rust 2018 after its release, just like we continued to add features to Rust after the Rust 1.0 release." Is it being feature frozen or not? I'm confused.
  - steveklabnik 8y ago
    When something lands in a particular edition, that’s a minimum edition. So a “Rust 2018 feature” will work in 2018 only, but a “Rust 2015 feature” will work in both 2015 and 2018. The “frozen” bit means that the features that are specific to Rust 2018 must be set when it is initially released. But new features that aren’t specific to it will still end up being added. So for example, Rust 1.31 will add the “impl_header_lifetime_elision” feature. It does not require Rust 2018, as it is backwards compatible. As such, it’s a “Rust 2015” feature, but it will work in both. A feature like async/await requires the async keyword. New keywords are not backwards compatible. As such, it will require Rust 2018, and will not work in 2015. However, if we release “Rust 2021” in three years, it will still work in that. Does that make sense?
    - Dylan16807 8y ago
      That makes sense, but I think "feature frozen" is the worst possible term to use here. Only the backwards compatibility gets frozen, not the set of features. And "specific to Rust 2018" is also an awkward term. From context I think that means the set of features that are part of Rust 2018 and also existed on its release day? But that meaning is not obvious. Is there any other term that means "the Rust 2018 set of features, as it was on release day"? It seems like something that really should have a clear name.
      - steveklabnik 8y ago
        Yeah, obviously we're struggling here a bit, which means there's some way to get this across better. > From context I think that means the set of features that are part of Rust 2018 and also existed on its release day? The "also existed on its release day" is redundant; they have to be in place on release day. If they weren't, then they'd be breaking.
        Dylan16807 8y ago
        > So for example, Rust 1.31 will add the “impl_header_lifetime_elision” feature. It does not require Rust 2018, as it is backwards compatible. As such, it’s a “Rust 2015” feature, but it will work in both. > The "also existed on its release day" is redundant; they have to be in place on release day. If they weren't, then they'd be breaking. I don't know how to reconcile these two sentences.
        steveklabnik 8y ago
        The former is not about a feature that requires Rust 2018. So the latter does not apply to it at all.
        Dylan16807 8y ago
        But just like you can add a "Rust 2015" feature after 2015, you can add a "Rust 2018" feature after 2018, right? If yes, then how do you best distinguish "Rust 2018 with additions" from "Rust 2018, the original 2018 version"? If no, then there are some extremely misleading descriptions of what an 'edition' is, because they don't mention that 2015 is special.

Everything goes in 2015 unless it would need to be backwards incompatible. Other editions, like 2018, have their feature sets frozen upon release. (Though there can be small details here; for example, at launch, 2018 will have the async keyword reserved but not implemented, the implementation will come later.)

Dylan16807 8y ago
So 2015 and 2018 are going to have mutually incompatible features at some point in the future? If 2015 is the only one that won't be generally feature-frozen, it really should have had a different-looking name. Edit: That blog post says "We’ll continue to add features to Rust 2018 after its release, just like we continued to add features to Rust after the Rust 1.0 release." Is it being feature frozen or not? I'm confused.
- steveklabnik 8y ago
  When something lands in a particular edition, that’s a minimum edition. So a “Rust 2018 feature” will work in 2018 only, but a “Rust 2015 feature” will work in both 2015 and 2018. The “frozen” bit means that the features that are specific to Rust 2018 must be set when it is initially released. But new features that aren’t specific to it will still end up being added. So for example, Rust 1.31 will add the “impl_header_lifetime_elision” feature. It does not require Rust 2018, as it is backwards compatible. As such, it’s a “Rust 2015” feature, but it will work in both. A feature like async/await requires the async keyword. New keywords are not backwards compatible. As such, it will require Rust 2018, and will not work in 2015. However, if we release “Rust 2021” in three years, it will still work in that. Does that make sense?
  - Dylan16807 8y ago
    That makes sense, but I think "feature frozen" is the worst possible term to use here. Only the backwards compatibility gets frozen, not the set of features. And "specific to Rust 2018" is also an awkward term. From context I think that means the set of features that are part of Rust 2018 and also existed on its release day? But that meaning is not obvious. Is there any other term that means "the Rust 2018 set of features, as it was on release day"? It seems like something that really should have a clear name.
    - steveklabnik 8y ago
      Yeah, obviously we're struggling here a bit, which means there's some way to get this across better. > From context I think that means the set of features that are part of Rust 2018 and also existed on its release day? The "also existed on its release day" is redundant; they have to be in place on release day. If they weren't, then they'd be breaking.
      - Dylan16807 8y ago
        > So for example, Rust 1.31 will add the “impl_header_lifetime_elision” feature. It does not require Rust 2018, as it is backwards compatible. As such, it’s a “Rust 2015” feature, but it will work in both. > The "also existed on its release day" is redundant; they have to be in place on release day. If they weren't, then they'd be breaking. I don't know how to reconcile these two sentences.
        steveklabnik 8y ago
        The former is not about a feature that requires Rust 2018. So the latter does not apply to it at all.
        Dylan16807 8y ago
        But just like you can add a "Rust 2015" feature after 2015, you can add a "Rust 2018" feature after 2018, right? If yes, then how do you best distinguish "Rust 2018 with additions" from "Rust 2018, the original 2018 version"? If no, then there are some extremely misleading descriptions of what an 'edition' is, because they don't mention that 2015 is special.