Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rochester!cornell!uw-beaver!mit-eddie!husc6!necntc!ima!haddock!karl
From: karl@haddock.UUCP (Karl Heuer)
Newsgroups: comp.lang.c
Subject: Re: type-indexed arrays
Message-ID: <587@haddock.UUCP>
Date: Fri, 19-Jun-87 14:26:25 EDT
Article-I.D.: haddock.587
Posted: Fri Jun 19 14:26:25 1987
Date-Received: Mon, 22-Jun-87 03:31:40 EDT
References: <139@starfire.UUCP> <516@haddock.UUCP> <20540@sun.uucp> <566@haddock.UUCP> <21213@sun.uucp>
Reply-To: karl@haddock.ISC.COM.UUCP (Karl Heuer)
Organization: Interactive Systems, Boston
Lines: 53
Summary: How to make the array a real datatype

In article <21213@sun.uucp> guy%gorodish@Sun.COM (Guy Harris) writes:
>[karl@haddock.isc.com (Karl Heuer) writes:]
>>[2] Discard the idea that a[i] means *(a+i), and the automatic conversion of
>>arrays to pointers.  This is probably best in the long run, but is a rather
>>substantial change in the language, and would have to be phased in.
>
>Note that C++ has implicitly acknowledged that [this model] isn't always
>right; [you can redefine subscripting for new types].  I agree that it would
>be best in the long run, but one is reminded of Keynes' remark [...]

So maybe we should just shorten the long run.  If we want to phase in this
change, I would expect that the first step would be to redefine subscripting
and array/pointer conversion as follows:

3.2.2.1 [Conversion of] Arrays, functions and pointers
Add the following paragraph:
    When used as an operand where an array is required, an expression that has
    type "pointer to _type_" is converted to an expression that has type
    "array of _type_ with unknown number of elements" whose initial member is
    pointed to by the pointer expression.

3.3.2.1 Array subscripting
Change the "constraints" paragraph:
    The left expression shall have type "array of _type_", the right
    expression shall have integral type, and the result has type "_type_".
Change the first "semantics" paragraph:
    E1[E2] designates the E2-th member of E1 (counting from zero).  Because of
    the conversion rule that applies to the subscripting operator, if E1 is a
    pointer to the initial member of an array object, E1[E2] is identical to
    (*(E1+(E2))).

This is just the reverse of the current wording*; the notational equivalence
of brackets and star-plus becomes a consequence instead of a definition.  I
claim that this change (along with appropriate rewording elsewhere in the
document) would not affect the behavior of the abstract machine at all.**
(Am I right?)  Thus, this change would be transparent to existing programs and
could be made immediately.

The hard part would be deprecating the use of "a" when "&a[0]" is meant.

Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint
--------
*Note that X3J11 has already done something very similar by changing the
definition of the function-call operator: instead of the left expression being
a function locator, and allowing the use of non-dereferenced function pointers
by implicitly dereferencing them, they asserted that the expression is
*always* a function pointer, and that the normal usage implicitly takes the
address of the function locator.  Personally I think they went the wrong
direction; I'd rather have functions and function pointers be distinct, and
require the "&" as well as the "*".

**Well, actually my wording does forbid the barbaric construct i[a], but this
could be either allowed-but-deprecated or a Common Extension.