Daniel Berlin wrote: > Sorry, but it's rather impossible to argue against someone who seems > to believe users should not be responsible and held responsible for > knowing the rules of the language they are programming in. Down this > path, madness lies. > "strict aliasing" is really just "what the standard says about > accessing memory and objects". > It's not "strict", or "arcane argumentation". It's just what a C > compiler is supposed to enforce. > > If ya'll want to invent and program in some relaxed variant of C with > less rules, fine. But don't call it C and don't pretend it is the C > language.
The point is: Which C language? The one I teethed on (circa 1974)? The "classic", with proper structure extensions? 1989? 1999? The current draft proposal? Changing syntax and semantics should not be impossible (it's being done), but it must be glacially slow, deliberate, with compelling need, and with years of warning around it. And not just warnings seen and heard only by folks who participate in standards committees and compiler development. By real warnings in compilers that wake people to the fact that the semantics of their coding style are in the process of being altered, so watch out. Instead, the attitude seems to be that if you have not a full nuanced grasp of the full meaning of the standard that your compiler was written to, well, then, you just should not consider yourself a professional programmer. OTOH, if "professional programmers" should have such a grasp, then why is it all these language lawyers are spending so much time arguing over what everyone ought to be able to understand from the documents themselves? My main point is simply this: change the language when there is compelling need. When there is such a need, warn about it for a few years. Not everybody (actually, few people) reads all the literature. Nearly everybody likely does read compiler messages, however. WRT strict aliasing, I've never seen any data that indicated that the language change was compelling. Consequently, as best I can tell it was a marginal optimization improvement. So, I doubt its value. Still, it should have had compiler warnings in advance.