> If we had this in C++ you could compile one file/module with C++11 and another with C++20.
I'm not 100% confident but I think you can do this already*. What you can't do, is compile each file with a different compiler or stdlib release.
There's just no reason to do it because C++11 and C++20 are forwards and backwards compatible, so you might as well compile everything with C++20 if you're already going to compile it all from source.
* An exception is omnibus libraries like abseil that take it upon themselves to backport stdlib features to older language versions. For example, abseil uses typedefs to define e.g. absl::optional as std::optional on newer versions or a custom implementation on older versions. If you compile abseil with C++11 and your client code with C++20, then you may end up with scary runtime errors (not compiletime, because templates are compiled in every translation unit, and not linktime, because the linker ignores types).
> There's just no reason to do it because C++11 and C++20 are forwards and backwards compatible, so you might as well compile everything with C++20 if you're already going to compile it all from source.
This isn't exactly true. The programming language version is one dimension of the problem, but there are a few other dimensions. For instance, some projects enable/disable features based on the language version, and that leads to unexpected errors. I recall that Boost caused a bunch of problems when upgrading a compiler version on a old legacy project just because the subproject enabled constexpr on C++11 which caused obscure linker errors out of nowhere.
There is far more to language version upgrades, and even compiler version upgrades, than flipping a switch.
Yep, that’s right. I would include that in the same exception that I listed, where libraries can choose to reflect on the language version that they are compiled with and expose different behavior that can cause issues.
I should mention that the pedantic reason why I have experience with this is that it is usually okay to compile and link with distribution-provided binary packages (where you don’t control the language version) as long as you use the distribution-provided toolchain, and upgrading the language version that you use for your code won’t cause any issues unless one of your dependencies is doing this kind of reflection. Some Linux distros will provide separate versions of packages for each language version in order to solve the problem for libraries like abseil and boost.
In circle the features are literally per-file. Which means you can have a source file that enables a feature and which include headers which doesn't use that feature, which in turn includes another one that includes that header etc.
At first look it seems that the problem is self inflicted and that if we got rid of headers and use modules c++ would be like rust.
But even in rust, editions can only be applied at the level of a crate. Crates are effectively the compilation units of rust
What circle does is more granular and it would be the equivalent of a rust edition per module or pet file.
I'm not 100% confident but I think you can do this already*. What you can't do, is compile each file with a different compiler or stdlib release.
There's just no reason to do it because C++11 and C++20 are forwards and backwards compatible, so you might as well compile everything with C++20 if you're already going to compile it all from source.
* An exception is omnibus libraries like abseil that take it upon themselves to backport stdlib features to older language versions. For example, abseil uses typedefs to define e.g. absl::optional as std::optional on newer versions or a custom implementation on older versions. If you compile abseil with C++11 and your client code with C++20, then you may end up with scary runtime errors (not compiletime, because templates are compiled in every translation unit, and not linktime, because the linker ignores types).