As long as old code continues to compile and run correctly on new compiler/language versions, I don't care what the committee does. From my point of view they should first and formost decelerate, so that there is at least enough time for compiler writers to keep up and collect enough experience between the standards. Cross-compiler compatibility has become an adventure since C++11. I only use a very conservative subset of the language to maintain compatibility.
C++ has become such an unwieldy monster that even though I've been primarily a C++ programmer from the very start of the language and am an expert in it, I've come to dread using it or maintaining software written in it.
Anything that stops or slows down the madness is welcome.
I like the Rust way of telling the compiler driver with a command line switch which compiler version to run, then backward compatibility as a problem disappears.
As long as old code continues to compile and run correctly on new compiler/language versions, I don't care what the committee does. From my point of view they should first and formost decelerate, so that there is at least enough time for compiler writers to keep up and collect enough experience between the standards. Cross-compiler compatibility has become an adventure since C++11. I only use a very conservative subset of the language to maintain compatibility.
C++ has become such an unwieldy monster that even though I've been primarily a C++ programmer from the very start of the language and am an expert in it, I've come to dread using it or maintaining software written in it.
Anything that stops or slows down the madness is welcome.
I like the Rust way of telling the compiler driver with a command line switch which compiler version to run, then backward compatibility as a problem disappears.
If they decide to accept the Safe C++ proposal, it will require it. We’ll see.
I have no skin in the game and rarely code in C++. My answer is: no.