4 ms·

It's similar in Rust, you specify the language edition with a line in Cargo.toml. https://doc.rust-lang.org/nightly/edition-guide/editions/creating-a-new-proje

It's similar in Rust, you specify the language edition with a line in Cargo.toml. https://doc.rust-lang.org/nightly/edition-guide/editions/creating-a-new-project.html https://doc.rust-lang.org/nightly/edition-guide/editions/cre...

umanwizard 7y ago
Rust language editions are not similar to C++ standard versions. Every new version of the Rust compiler brings changes to the language, so the language you're actually using depends on the tuple (compiler version, edition), not just on the edition.
- the_why_of_y 7y ago
  Rust language editions are similar but not equivalent to C++ standard versions, because compiling code written for an old edition with a new edition is not guaranteed to work, due to breaking language changes like new keywords. But you are correct to point out that old Rust editions will get new language features if they do not break existing code. https://hacks.mozilla.org/2018/12/rust-2018-is-here/ https://hacks.mozilla.org/2018/12/rust-2018-is-here/ The release process claims that the changes in new Rust releases are purely additive and backward compatible; the only exception is soundness fixes, which I'd expect affect a negligible amount of code.
  - umanwizard 7y ago
    > compiling code written for an old edition with a new edition is not guaranteed to work, due to breaking language changes like new keywords. This is not at all similar to C++ standards, and the specific case being discussed in this post demonstrates exactly why! Barring bugs in implementations, developers could develop against whatever version of the compiler they like, and as long as it supports the same language version, distro or OS maintainers wouldn’t have to update theirs, and everything would work. I worked on an open-source project that targeted C++11. It could build on basically any Linux distro you can imagine, even ones with very old versions of GCC. (it didn’t support BSD, but for unrelated reasons). This is the point the Rust project seems to miss when harping on about backwards compatibility: forwards compatibility is just as important.
    - the_why_of_y 7y ago
      Okay, I see what you mean; I guess if I were a Rust programmer I'd solve that by using rustup to install a fixed Rust release for development. However the Firefox project has decided to always require the latest stable Rust release. https://news.ycombinator.com/item?id=22022834 https://news.ycombinator.com/item?id=22022834 In practice for C++ I've found it expedient to whitelist some subset of functionality from newer standards, because there's often useful features that already work in the major 3 compilers, but it'll be another 3 years until the last of the compilers adds the last obscure bits for full support of the new standard.

umanwizard 7y ago

Rust language editions are not similar to C++ standard versions. Every new version of the Rust compiler brings changes to the language, so the language you're actually using depends on the tuple (compiler version, edition), not just on the edition.

the_why_of_y 7y ago
Rust language editions are similar but not equivalent to C++ standard versions, because compiling code written for an old edition with a new edition is not guaranteed to work, due to breaking language changes like new keywords. But you are correct to point out that old Rust editions will get new language features if they do not break existing code. https://hacks.mozilla.org/2018/12/rust-2018-is-here/ https://hacks.mozilla.org/2018/12/rust-2018-is-here/ The release process claims that the changes in new Rust releases are purely additive and backward compatible; the only exception is soundness fixes, which I'd expect affect a negligible amount of code.
- umanwizard 7y ago
  > compiling code written for an old edition with a new edition is not guaranteed to work, due to breaking language changes like new keywords. This is not at all similar to C++ standards, and the specific case being discussed in this post demonstrates exactly why! Barring bugs in implementations, developers could develop against whatever version of the compiler they like, and as long as it supports the same language version, distro or OS maintainers wouldn’t have to update theirs, and everything would work. I worked on an open-source project that targeted C++11. It could build on basically any Linux distro you can imagine, even ones with very old versions of GCC. (it didn’t support BSD, but for unrelated reasons). This is the point the Rust project seems to miss when harping on about backwards compatibility: forwards compatibility is just as important.
  - the_why_of_y 7y ago
    Okay, I see what you mean; I guess if I were a Rust programmer I'd solve that by using rustup to install a fixed Rust release for development. However the Firefox project has decided to always require the latest stable Rust release. https://news.ycombinator.com/item?id=22022834 https://news.ycombinator.com/item?id=22022834 In practice for C++ I've found it expedient to whitelist some subset of functionality from newer standards, because there's often useful features that already work in the major 3 compilers, but it'll be another 3 years until the last of the compilers adds the last obscure bits for full support of the new standard.