5 ms·

> NLL will be enabled in Rust 2015 sometime early next year Wouldn't that be 2019 not 2015?

portmanteaufu 8y ago
"Rust 2015" and "Rust 2018" are referring to editions[1] of the language. > Rust ships releases on a six-week cycle. This means that users get a constant stream of new features. This is much faster than updates for other languages, but this also means that each update is smaller. After a while, all of those tiny changes add up. But, from release to release, it can be hard to look back and say "Wow, between Rust 1.10 and Rust 1.20, Rust has changed a lot!" > Every two or three years, we'll be producing a new edition of Rust. Each edition brings together the features that have landed into a clear package, with fully updated documentation and tooling. New editions ship through the usual release process. [1] https://rust-lang-nursery.github.io/edition-guide/editions/index.html https://rust-lang-nursery.github.io/edition-guide/editions/i...
steveklabnik 8y ago
Nope. “Rust 2015” is a term of art in this context. https://blog.rust-lang.org/2018/07/27/what-is-rust-2018.html https://blog.rust-lang.org/2018/07/27/what-is-rust-2018.html
- mitchty 8y ago
  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.

"Rust 2015" and "Rust 2018" are referring to editions[1] of the language. > Rust ships releases on a six-week cycle. This means that users get a constant stream of new features. This is much faster than updates for other languages, but this also means that each update is smaller. After a while, all of those tiny changes add up. But, from release to release, it can be hard to look back and say "Wow, between Rust 1.10 and Rust 1.20, Rust has changed a lot!" > Every two or three years, we'll be producing a new edition of Rust. Each edition brings together the features that have landed into a clear package, with fully updated documentation and tooling. New editions ship through the usual release process. [1] https://rust-lang-nursery.github.io/edition-guide/editions/index.html https://rust-lang-nursery.github.io/edition-guide/editions/i...

steveklabnik 8y ago

Nope. “Rust 2015” is a term of art in this context. https://blog.rust-lang.org/2018/07/27/what-is-rust-2018.html https://blog.rust-lang.org/2018/07/27/what-is-rust-2018.html

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