The D Programming Language (was: Still more new operators)

[Mark Brader]

> 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 at sq.com				-- Michael DeCorte