5 ms·

The big news for me here is that NLL seems about to ship, that's great to hear. That will alleviate easily 90% of my frustrations with the current block-based c

by simias 8y ago

The big news for me here is that NLL seems about to ship, that's great to hear. That will alleviate easily 90% of my frustrations with the current block-based checker.

Tuna-Fish 8y ago
NLL is the default in the beta channel, and will ship as default on stable in exactly 30 days.
nicoburns 8y ago
Yep, it should be in the next Rust release (in about a month). This will also be the first release to support Rust 2018.
steveklabnik 8y ago
To be a bit more precise than my siblings: NLL is on by default in the Rust 2018 mode of the Rust 1.31 release, shipping December 6. NLL will be enabled in Rust 2015 sometime early next year, we do not have a precise release yet.
- mitchty 8y ago
  > 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?
- cornstalks 8y ago
  I'm a bit confused by this. I thought (probably incorrectly) that the point of Rust editions was that if you targeted Rust 2015, it would compile with Rust v1.0. But if you enable NLL in Rust 2015 mode, that code will no longer compile with Rust v1.0. Which means we're still back at square 1 (meaning each crate has to specify which compiler version it requires). Could you help enlighten me on why this is safe to backport to Rust 2015?
  - steveklabnik 8y ago
    “Rust 2015” does not mean “Rust 1.0.” Editions are a way to opt into changes that would be breaking. New features land in Rust 2015 unless they require breaking changes, and if they do, they must wait until the next edition to land, because otherwise they’d be breaking.
  - kibwen 8y ago
    I think you're talking about forward compatibility, which is distinct from backward compatibility. With backward compatibility, old programs will work with new versions of the compiler (alternatively, for web browsers, "old websites will work with new versions of the browser" (or for operating systems, "old binaries will work with new versions of the OS" (or for game consoles, "old games will work with new versions of the console", etc.))). In this case, code written as of Rust 1.0 should continue compiling with Rust 2015, respective of the compatibility guarantee ( https://blog.rust-lang.org/2014/10/30/Stability.html https://blog.rust-lang.org/2014/10/30/Stability.html ). By this definition, Rust is backwards-compatible. What Rust is not, and has never been, is forwards-compatible. Very few systems in the wild are forwards-compatible. A C++ compiler from 2003 is not able to compile C++17 programs, and is thus not forwards-compatible. Likewise, web browsers from 2003 cannot render web pages from 2018, Windows ME cannot run binaries compiled for Windows 10, PS2 cannot play PS4 games, and so on. > meaning each crate has to specify which compiler version it requires Every Rust crate that does not specify a compiler version is compiled in 2015 mode. It must be this way, for backwards-compatibility. However, when you run `cargo new`, cargo should automatically insert the directive specifying the most recent edition supported by your compiler. In this way, Rust can gradually push the ecosystem forward without any additional burden to the user and without leaving behind any code that doesn't update.

by simias 8y ago

The big news for me here is that NLL seems about to ship, that's great to hear. That will alleviate easily 90% of my frustrations with the current block-based checker.

Tuna-Fish 8y ago

NLL is the default in the beta channel, and will ship as default on stable in exactly 30 days.

nicoburns 8y ago

Yep, it should be in the next Rust release (in about a month). This will also be the first release to support Rust 2018.

steveklabnik 8y ago

To be a bit more precise than my siblings: NLL is on by default in the Rust 2018 mode of the Rust 1.31 release, shipping December 6. NLL will be enabled in Rust 2015 sometime early next year, we do not have a precise release yet.

mitchty 8y ago
> 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?
cornstalks 8y ago
I'm a bit confused by this. I thought (probably incorrectly) that the point of Rust editions was that if you targeted Rust 2015, it would compile with Rust v1.0. But if you enable NLL in Rust 2015 mode, that code will no longer compile with Rust v1.0. Which means we're still back at square 1 (meaning each crate has to specify which compiler version it requires). Could you help enlighten me on why this is safe to backport to Rust 2015?
- steveklabnik 8y ago
  “Rust 2015” does not mean “Rust 1.0.” Editions are a way to opt into changes that would be breaking. New features land in Rust 2015 unless they require breaking changes, and if they do, they must wait until the next edition to land, because otherwise they’d be breaking.
- kibwen 8y ago
  I think you're talking about forward compatibility, which is distinct from backward compatibility. With backward compatibility, old programs will work with new versions of the compiler (alternatively, for web browsers, "old websites will work with new versions of the browser" (or for operating systems, "old binaries will work with new versions of the OS" (or for game consoles, "old games will work with new versions of the console", etc.))). In this case, code written as of Rust 1.0 should continue compiling with Rust 2015, respective of the compatibility guarantee ( https://blog.rust-lang.org/2014/10/30/Stability.html https://blog.rust-lang.org/2014/10/30/Stability.html ). By this definition, Rust is backwards-compatible. What Rust is not, and has never been, is forwards-compatible. Very few systems in the wild are forwards-compatible. A C++ compiler from 2003 is not able to compile C++17 programs, and is thus not forwards-compatible. Likewise, web browsers from 2003 cannot render web pages from 2018, Windows ME cannot run binaries compiled for Windows 10, PS2 cannot play PS4 games, and so on. > meaning each crate has to specify which compiler version it requires Every Rust crate that does not specify a compiler version is compiled in 2015 mode. It must be this way, for backwards-compatibility. However, when you run `cargo new`, cargo should automatically insert the directive specifying the most recent edition supported by your compiler. In this way, Rust can gradually push the ecosystem forward without any additional burden to the user and without leaving behind any code that doesn't update.