Checksum: 15612 Lines: 39 Path: utzoo!sq!msb From: msb@sq.uucp (Mark Brader) Date: Thu, 25-Feb-88 19:19:57 EST Message-ID: <1988Feb25.191957.6926@sq.uucp> Newsgroups: comp.lang.c Subject: Re: The D Programming Language (was: Still more new operators) Summary: arrays and pointers References: <11702@brl-adm.ARPA> <243@eagle_snax.UUCP> <2245@geac.UUCP> <2718@mmintl.UUCP> Reply-To: msb@sq.UUCP (Mark Brader) Organization: SoftQuad Inc., Toronto > Any serious effort to design a successor to C (which does not attempt to > be upward compatible) should first consider what should be taken out and/or > done differently. Adding new things is secondary. > > The first thing I would remove is the automatic conversion of arrays to > pointers. So far I agree. > (A consequence of this change is that "a[b]" is no longer definable as > "*(a + b)". Here I disagree. We can have it both ways. Allow automatic conversion of arrays to pointers *where pointers are required*. That is, if you say "b = a;", where a is an array, you get *either* a pointer assignment or an array assignment, depending on whether b is a pointer or array variable. The present definitions of * and [] can then be happily retained. In fact, the entire present treatment of arrays can be happily retained, and thus arrays-as-first-class-objects could go into C itself -- except for one thing. Function calls. If the rule was that a prototype of the form "void fun (int a[4], int *b);" declared a function with one array and one pointer argument, then calls to this function could follow the semantics I outlined above; a call of the form fun(a,a); would pass the whole array a as the first argument, and a pointer to its start as the second argument. (Barring some form of "conformant arrays", the dimension 4 would have to match exactly.) Of course, in the present draft, that declaration declares a function with two pointer arguments. If this becomes as entrenched in the language in connection with the new prototype syntax as it is with the old function definition syntax, we will never get arrays-as-first-class-objects. This is one reason why I and others have suggested that declarations such as the above should at least cease to have their present meaning. Mark Brader "C takes the point of view SoftQuad Inc., Toronto that the programmer is always right" utzoo!sq!msb, msb@sq.com -- Michael DeCorte