noalias (was: Re: the "const" qualifier)

[Doug Gwyn]

In article <1989Oct19.162849.20265 at utzoo.uucp> henry at utzoo.uucp (Henry Spencer) writes:
>In article <742 at ccssrv.UUCP> perry at ccssrv.UUCP (Perry Hutchison) writes:
>>+ Many of us think "noalias", with the problems in its specification
>>+ straightened out, would have been a better solution, but
>>+ it wasn't politically feasible to reintroduce such a qualifier.
>>  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>In other words, a _technically_ defective hack was put in the standard at
>>the last minute, to satisfy someone's _political_ agenda.
>Well, yes, but not in the way you meant it.  A technically defective hack
>("noalias") was indeed put in the standard at the last minute (second public
>review) to satisfy someone's (the number crunchers') semi-political agenda.
>There was, quite legitimately and properly, a storm of protest from almost
>everyone else in sight, including Dennis Ritchie.  Partly because the hack
>really was technically defective, as written.  So it got hastily taken out
>again.  Something along those lines might indeed have been the best solution,
>but it was introduced far too late and without adequate prior thought.  If
>I am not mistaken, it was also an invention of the committee rather than
>proven prior art, which is a big no-no for a standards committee.

I'm being proven right in my expressed reluctance to explain all that..

Another way to look at it is that there was a clearly perceived deficiency,
and due to time pressure (from many sides) the attempted solution had some
flaws in its specification.  The whole issue became very political, mainly
because Dennis was quite outspoken against the whole notion of type
qualifiers.  Therefore a technically defective (but repairable) feature
was REMOVED at the last minute, leaving a void which had to be covered by
some compromise juggling of the type qualifiers we had left.  There still
is no official support for the kind of improved optimization that "noalias"
would have supported.  However, "const" is able to signify both "really
constant" AND "read only", even though it's stretching the notion a bit to
attempt to cover both meanings.  In the process, only the first two levels
of function parameters were specified so that casts are not necessary to
outwit "const" type qualifiers.  I believe we got the wording right for
that, after many rewrites, and from the experience I'm glad we didn't try
to specify this attribute at ALL parameter indirection levels.

It was certainly within X3J11's mandate to invent solutions -- when
necessary to remedy clearly perceived deficiencies.  "Prior art", while
important, could not be used as the sole criteria for making decisions.
In fact, practically every interesting technical decision in drafting
the Standard had good arguments on all sides, and there were a lot of
"judgement calls" required after all sides had been heard.

If you know some better way to draft such a standard, more power to you.
We did the best we could, and I think our consciences are clear.