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.