C subscripts

[Doug Gwyn <gwyn>]

> Who else out there thinks that
> 	some_array_name[more][long][names]
> is actually a good way to do things?

I do.  There is a deeper meaning to C arrays than to Fortran arrays.

> Just as we need nested comments, because after all other "great languages"
> do, I propose that C support "normal" subscripting.

We DON'T need nested comments.  I brought up the issue solely because I
was getting bored and wanted a new topic for discussion.

> Mathematicians have been around longer than C; Fortran too;
> so, in the name of compatability, which is what the ANSI standard
> is all about anyway, the compiler SHOULD accept 
> 	some_array_name[more,long,names]

Most mathematicians seldom write subscripts that way!
C is not FORTRAN.  Why should it worry about "compatibility" of appearance?

> I would also propose one small, new, preprocessor built-in,
> 	SUBTYPE  which would be defined OLD or NEW
> as in 
> 	#if SUBTYPE == OLD
> 		fprintf(stder, "buy a new compiler");
> so programmers know what's going on.

This is exactly the sort of thing we DON'T want in the new standard.

> Now, BEFROE the flames start I KNOW the comma operator exists.
> This is not overloading because subscripts are expressions, not statements.
> So don't start quoting K&R pg 192 to me.

You're right that it's not overloading.  What it is, is AMBIGUOUS.

	type	data[M][N];	/* or as you wish, [M,N] (also ambiguous) */
	data[i];		/* unambiguously a pointer to (type) */
	data[i][j];		/* unambiguously a (type) */
	data[i,j];		/* under existing rules, a pointer to (type);
				   under your proposal, AMBIGUOUS */

Arrays are definitely second-class citizens in C; pointers are full citizens.
I hope the ANSI C committee cleans this up, but leaving [][] syntax intact
seems essential.