Aside from the header issue, it doesn't allow for or support backwards-incompatible changes.
Because editions are opt-in (and library-level source metadata) the language itself can be modified in non-backwards-compatible ways.
So for instance a C++ with editions could make ctors `explicit` by default, or it could entirely change the automatic member generation (by removing it for instance). As long as the ABI and API remain compatible, that's fine.
It’s probably worth noting that the backwards compatibility breaking changes I think only applies to the language and not the standard library. I’m unable to look up the details right now but I believe there’s a trait function defined in stdlib which is deprecated, supersede, but can’t be removed even as part of an Edition, or it would break older code.
That is correct, editions are mostly about language-level syntactic changes, the APIs have to be compatible between editions. The only place where that isn't the case is the standard prelude (the "builtins" you don't have to import).
The ability to replace the prelude does mean that you can imagine if somebody invents a much better thing than, say, Rust's iterators Rust 2050 can have a prelude that brings in std::better::Iterator instead of std::iter::Iterator and then most coders will end up using the new better iterators, just because that's the kind you get out of the box.
Anybody who literally refers to std::iter::Iterator gets the old ones of course as does any library code from prior editions, but the documentation could lead those few people in the right direction. And presumably std::better::Iterator politely implements std::iter::IntoIterator because why not.
I would be interested to understand if they're allowed to replace the macros. The standard macros aren't actually from the prelude, but instead if you aren't no_std you get all the standard macros anyway. Are they allowed to change those in a future edition? Or not?
Personally I'd kinda like it if preludes were decoupled from editions in some way. Like, fine to have a default per-edition but there are times I would really like to have a prelude without all the `impl<T> X for T`s included.
You can kinda do this now with `#[no_implicit_prelude]` I think but it has somewhat odd semantics. It applies to all submodules, unlike most attributes, and then if you define your own prelude you need to use it in every submodule because they won't all have their own.
If it's gonna have global effect I think it'd be better if it was:
#[prelude]
mod my_prelude {
use std::whatever::*;
}
and then my_prelude would be included in all submodules by default.
Seems like it ought to new possible to rename std::iter::Iterator to std::iter::OldIterator, add std::iter::NewIterator, and then vary which iterator std::iter::Iterator points to based on edition.
Maybe that would be considered too confusing though.
Yes. If the only value the library brings to you is that it generates a particular object file, you can divorce that object file from your chosen language version entirely.
If you have libraries that you don't care if they're C or Pascal or a Lisp implemented in raw machine code, then this works just fine and you needn't care about Rust's editions feature. Rust will also cheerfully consume these libraries although of course everything about them is by definition Unsafe in Rust terms.
But most people want their C++ libraries to deliver a bit more than "Here is some machine code, and here are some symbol names that map to the machine code or to raw binary data". Like maybe they want to be able to implement an Interface the library describes, or they want to use a Concept the library names. You can't do those things using language-independent object files.
Rust library A, from edition 2021 can implement a Trait from library B (edition 2018) on its thin wrapper of a type from library C (edition 2015) and then you can consume the resulting type, with its trait implementation, from your Rust 2018 program.
The problem is a C++ library's headers must be compiled with the settings, context, and flags of every downstream thing that depends on them, rather than separately.
Which isn't such a big problem if your C++ library exposes a minimal C-like API from it's headers, with most of the meat of the library hidden away in source files, but might be a very big problem if your C++ library is a miserable little pile of ~~secrets~~ templates, a la boost.
Yes, because C versions are frozen in time, and editions aren't. Today Rust added brand new features to Rust 2015 and Rust 2018, and will continue to expand them forever (every new feature lands in all editions whenever possible).
Rust editions are closer to source code parsing modes. More like enabling trigraphs in C or "use strict" in JS.
Additionally, textual header inclusion in C makes mixing versions tricky. Rust has properly isolated crates, and tracks edition per AST node (so that even cross-crate macros work correctly with mixed editions).
C compilers usually backport features in older standards as well (I know, they are breaking the standard). One example are C++ style comments, that are in the standard only from C99, but basically every compiler supports them even in ANSI/C90 mode.
By the way the difference is that Rust is not a standard, thus is easier to evolve (the process is much shorter). On the other side, the fact that a language changes slowly it's something good in a way, it means that you don't have to continue to change the way you do things, and update older projects.
That to everyone that has to maintain code for decades it's important. And every serious software project (not hobby stuff) does stay in production decades really. I don't use Rust, or even C++, for that reason.
> On the other side, the fact that a language changes slowly it's something good in a way, it means that you don't have to continue to change the way you do things, and update older projects.
Isn’t the point of Rust editions that this is also true for Rust? Don’t want to update to a new edition? Then… don’t. The old ones are maintained.
It's certainly true that if C++ library maintainers are up for the ever-growing maintenance burden, they can all individually deliver the same promise Rust gets out of the box.
This is in practice what the maintainers of the three standard libraries have to do, perhaps one or more of them will offer their opinion about that experience?
The maintainers would have to do it for every new language version that breaks them, though. The edition system keeps old stuff working without any effort.
I don't want to start this discussion thread yet again, but I am a firm believer that edition system only appears to work right now because:
1 - Rust is still quite young and doesn't have 30 years of accumulated editions
2 - There is still only one major Rust compiler
3 - Editions are designed only to work when compiling the whole project, including 3rd party dependencies, from source code within a single build
4 - So far the editions don't have semantic breaking changes across editions, where behaviour changes across the edition border
5 - There is no plan to ever have editions work across ABIs
So "The edition system keeps old stuff working without any effort." might not be true when Rust achieves an adoption scale similar to C and C++, in about 20 years, with several accumulated editions, and a couple of compilers in use.
I might be proven wrong, but that is how I see it today.
> 1 - Rust is still quite young and doesn't have 30 years of accumulated editions
Rust 1.0 was six years ago. When do we start the clock on six years of C++ evolving while also having "old stuff working without any effort" ?
C++ 98 to C++ 03 was five years, and that introduces almost no features at all. C++ 11 was eight years later but it's notoriously incompatible to prior versions of C++. C++ 14 is only three years, C++ 17 has breaking changes, as does C++ 20...
I think C++ 20 should have taken Epochs (yes even at considerable cost to other new features like Concepts) for this reason. I think ten years from now even if Rust has found it can't achieve everything it wants to via editions, this feature will be generally considered to be a good idea, like generics or string literals. Something you need a specific rationale for not including in your general purpose language.
I might be proven wrong too about how far this can go, but I feel like the Rust 2018 and 2021 editions already prove the value of the idea.
For starters epochs could never work in ecosystems that value binary libraries, regardless of possible ABI issues, which is also a reason why Apple went to such an effort to define an ABI alongside language versions.
Lets say you have a noexcept function compiled in C++20 that calls a throws() function, compiled in C++03, which actually ends up throwing, linked together.
What is the runtime supposed to do now?
To which semantics does it follow now?
Call std::unexpected() as it is supposed to do pre-C++14 or call std::terminate() as it should do in C++20?
What about the user defined handler that was configured for such scenario? Which of them gets called, or do both get called, in which order?
Maybe I am doing it more complex that it is, but I see several scenarios from point of view where multiple compilers, binary libraries and semantic changes come into play, editions turn just into another way to define language versions, because they don't cover all possible uses cases how a language might evolve.
Anyway, history will tell how things work out in the end.
You might well be right, but if the scheme lasts 20 years (and makes it easier to maintain old code during that period), I'd say it's a very good run by PL standards!
Because editions are opt-in (and library-level source metadata) the language itself can be modified in non-backwards-compatible ways.
So for instance a C++ with editions could make ctors `explicit` by default, or it could entirely change the automatic member generation (by removing it for instance). As long as the ABI and API remain compatible, that's fine.