Path: utzoo!mnetor!uunet!husc6!cmcl2!brl-adm!brl-smoke!gwyn From: gwyn@brl-smoke.ARPA (Doug Gwyn ) Newsgroups: comp.lang.c Subject: Re: Noalias trivia question Message-ID: <7805@brl-smoke.ARPA> Date: 30 Apr 88 15:59:03 GMT References: <56@lakart.UUCP> <1164@maccs.UUCP> Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) ) Organization: Ballistic Research Lab (BRL), APG, MD. Lines: 36 In article <1164@maccs.UUCP> gordan@maccs.UUCP () writes: >So, like, who on X3J11 will admit to having voted for (or worse, >proposed) noalias in the first place? Why did it seem like a good idea >at the time, and what were the reasons for dropping it (apart from >universal opprobrium). Enquiring minds &c. Unofficially speaking... "noalias" was worked out by a special task force at the December X3J11 meeting (originally without that particular name, just as the concept) as a compromise position that could be supported by two opposed sides of the optimization vs. aliasing battle. On the first day of that meeting, in a non-binding "straw vote" it was decided to change the semantics of "const" (which admittedly were not all that clear) from meaning "readonly" to meaning "really constant", in fact to allocate the eventual "const noalias" semantics to just "const". AT&T and some others adamantly opposed this. The task force determined that really this was another instance of overloading semantics onto a keyword, and that there were three, not two, orthogonal qualifiers needed to cover all the useful cases via multiplexing of qualifiers. Thus the third qualifier, eventually named "noalias". In April, we basically had a choice between fixing "noalias" (we did fix "const"), removing "noalias" and making "const" mean what had been decided on December-Monday, or removing "noalias" and leaving "const" with its "readonly" meaning. The latter approach was adopted as the most acceptable at this stage, although the second approach might have been adopted had we not gone through the "noalias" detour. Certainly having Dennis Ritchie participating in the April-Monday discussion helped clarify the issues and shape our final decision. I think we will be able to support the latest position against further onslaughts, even though we have now left the optimizers without a handle for performing the optimizations they sought in standard-conforming C. Removing *all* qualifiers, as suggested in a public comment by Rob Pike, found little support and not even Dennis was asking for that.