3 ms·

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 guar

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

> 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.