> If you expect anyone to adopt your new standard revision, the very least you need to do is ensure their code won't break just by flipping s flag.
Why would you expect that a new revision can't cause existing code to compile? It means that "new" revisions can't fix old problems, and one thing you always get more of over time is perspective.
If you don't want your code "broken", don't migrate to a new standard. That's the point of supporting old standards. Don't hobble new standards because you both want new things, but don't want old things to change.
> Why would you expect that a new revision can't cause existing code to compile?
For staters, because that would violate the goals and prioritites of the C++ as established by the C++ standardization committee.
I could go on and on, but it's you who should provide any semblance of rationale: why do you believe existing software should break? What value do you see in it? Does it have any value at all?
> why do you believe existing software should break? What value do you see in it? Does it have any value at all?
How exactly can a _new_ standard cause existing software compiling on an old standard to break?
EDIT: As to the value, I've mentioned elsewhere in this thread; we know a lot more about the practice of programming than when C++ was created and standardised. Why would we say those design decisions can never be questioned or changed? It locks into place choices we never knew were bad, until they caused decades of problems.
> that would violate the goals and prioritites of the C++ as established by the C++ standardization committee.
Correct. It's these goals and priorities that are being criticised.