What part could be removed without breaking backward compatibility?
Depending on what is removed and how, it creates a subset that is not fully C++.
What part could be removed without breaking backward compatibility?
Depending on what is removed and how, it creates a subset that is not fully C++.
There can still be the standard updates every 3 years for backwards compatibility, but Id assume version upgrades don't happen very frequently. Meaning, if a project is started on c++11 then it's probably going to stay on c++11 indefinitely, never making it to c++17 or some other later version.
If that's true then that would imply in general the projects using c++17 or later are created from scratch using that standard and therefore wouldn't suffer from backwards compatibility.
This is all said as someone who works with Java where I don't see folks migrating from Java 8 -> 11 or later.
You can use (depend on) a crate from your code that uses an old edition.
In C++, your idea would require enforcement at the compiler level but the linker should still link both "old" and "new" C/C++ together. Then the switch is done on a .cpp file (translation unit) level.
However the culture around C / C++ compiler development with standards and multiple compilers would require huge committees to decide what is "modern C++." There might be a lot of debate.
Much of the innovation in Python, C# and Rust is in how the process of language and standard library development is managed in the community. I wonder if C++ could do that?