Discussion about C array type semantics

14 points by schuelermine


spc476

I'm not a fan of the syntax. In fact, if you are going as far as changing C syntax, then get rid of the notion that pointers are arrays (for the most part) and have the compiler carry along the size of the array. Something like:

error process_array(struct foo list[])
{
  for (size_t i = 0 ; i < items(list) ; i++)
    ...
  return OKAY;
}

Declaring the function to take a pointer and trying to use items() (which returns the length of the array from the hidden "fat pointer") on it would be an error. In other words, arrays no longer decay into simple pointers. I still haven't worked out how to allocate a dynamic array from heap, but it's a start. Taking slices of an array could be as simple ("simple" ... heh) as:

int array1[100] = { ... }; /* initialize with some data */
int array2[] = { array[50..70] };
int array3[30] = { ... }; /* initialize with some data */
array3[15..] = { array3[16..] , 0 }; /* remove item 15, move the rest of the array down, fill in last item with 0 */

Basically, make arrays distinct from pointers.

And while we're here, I would get rid of the -> syntax. Compilers already know enough to error on struct foo *pfoo; pfoo.that = 3;. The compiler will let slide struct foo *pfoo; pfoo[0].that = 3 just fine. I see no need for the -> syntax anymore (and assume that struct foo *pfoo is properly initialized for the examples).