they don't work with a backward compatible application binary interface
or more specifically they only work with ABI stability if they ABI doesn't change between epochs
which isn't a issue for Rust because:
- it is cleanly modularized
- it build a whole module "at once"
- it doesn't have a "stable" ABI (outside of "extern/repr C" parts which don't contain non reprC parts rust doesn't even guarantee ABI compatibility between two builds in exactly the same context*(1))
- tends to build everything from source (with caching)
- a lot of internees are intentionally kept "unstable" so that they can change at any time
on the other side due to how C/C++ build things, doesn't have clean module isolation, how it chooses build units, how all of that is combined, how it's normal to include binaries not build by your project (or even you), how such binaries contain metadata (or don't) and how too much tooling relies on this in ways which make changes hard, how it doesn't have build-in package management, how it you specify compiler options and how compiler defaults are handled etc. come together to make that impossible
in a certain way how you specify that you use C++11,17 etc. is the closest C++ can get to rust editions
like initially it might seem easy to introduce syntax braking changes (which most rust edition changes boil down to) but then you realize that build units using other editions have to be able to read the header file and the header file e.g. in context of templates can contains any kind of code and that header includes aren't that much different too copy pasting in the header and that you don't have a standard package manager which can trace which edition a header has and endless different build systems and you kinda give up
purely technically it _is fully possible to have rust like editions in C++_ but practically/organizationally in context of e.g. backward compatibility with build systems it's just way to disruptive to be practical
or more specifically they only work with ABI stability if they ABI doesn't change between epochs
which isn't a issue for Rust because:
- it is cleanly modularized
- it build a whole module "at once"
- it doesn't have a "stable" ABI (outside of "extern/repr C" parts which don't contain non reprC parts rust doesn't even guarantee ABI compatibility between two builds in exactly the same context*(1))
- tends to build everything from source (with caching)
- a lot of internees are intentionally kept "unstable" so that they can change at any time
on the other side due to how C/C++ build things, doesn't have clean module isolation, how it chooses build units, how all of that is combined, how it's normal to include binaries not build by your project (or even you), how such binaries contain metadata (or don't) and how too much tooling relies on this in ways which make changes hard, how it doesn't have build-in package management, how it you specify compiler options and how compiler defaults are handled etc. come together to make that impossible
in a certain way how you specify that you use C++11,17 etc. is the closest C++ can get to rust editions
like initially it might seem easy to introduce syntax braking changes (which most rust edition changes boil down to) but then you realize that build units using other editions have to be able to read the header file and the header file e.g. in context of templates can contains any kind of code and that header includes aren't that much different too copy pasting in the header and that you don't have a standard package manager which can trace which edition a header has and endless different build systems and you kinda give up
purely technically it _is fully possible to have rust like editions in C++_ but practically/organizationally in context of e.g. backward compatibility with build systems it's just way to disruptive to be practical