Comment by ajross
3 months ago
> Introducing [...] new keywords [...] is not a breaking change.
This is some kind of semantic prestidigitation around a definition for "breaking" that I'm not following. Yes, obviously it is. New keywords were valid symbol names before they were keywords.
Makes me wonder if the "don't spread misinformation" quip was made in good faith.
It was. And no, breaking change is not what you seem to imply it is. When talking about breaking changes, introducing new keywords is not what people usually think of. It's irrelevant.
Sigh. "Irrelevant" except in the sense that the code used to build and now it doesn't after a gcc upgrade, you mean. This is an attitude shared (c.f. "greenfield" comments elsewhere in this tree) among a bunch of people who do intensive development and maintenance on active products all the time.
That use case is probably less than 20% of all the C++ development cycles out there. This is a 40 year old language that the bulk of the industry has decided to abandon for new work. The large majority of people doing work on this code are doing minimal-change updates, and nonsense like this is how you end up with rules like "We have to deploy on Ubuntu 20.04 still because the AbandonWare 4.7 library doesn't work on later version".
And it's avoidable, but not if you run around lying to people and yourself about what a breaking change is. Again, look at how C does this. The C standard writers actually know that they're updating a legacy environment and care deeply about full backwards compatibility.
Nonsense. Adding more keywords to a language is avoidable? Or making the compiler stricter in checking the integral promotions is avoidable? Sure, it is, but only if you stick compiling all of your code with C89. You're barking at the wrong door.
1 reply →