Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!mit-eddie!genrad!decvax!ima!haddock!karl
From: karl@haddock.UUCP (Karl Heuer)
Newsgroups: comp.lang.c
Subject: Re: type-indexed arrays (was: enum - enum ?)
Message-ID: <566@haddock.UUCP>
Date: Mon, 15-Jun-87 19:20:29 EDT
Article-I.D.: haddock.566
Posted: Mon Jun 15 19:20:29 1987
Date-Received: Sun, 21-Jun-87 04:09:48 EDT
References: <139@starfire.UUCP> <516@haddock.UUCP> <20540@sun.uucp> <526@haddock.UUCP>
Reply-To: karl@haddock.ISC.COM.UUCP (Karl Heuer)
Organization: Interactive Systems, Boston
Lines: 38

In <516@haddock.UUCP> and <526@haddock.UUCP> I suggested the possibility of a
type-indexed array, the particular point of interest being enums:
    enum color { RED, GREEN, BLUE };
    int hue[enum color] = { RED: 0x00F, GREEN: 0x0F0, BLUE: 0xF00 };
This is supposed to create an array which must be subscripted by enum color;
using an int subscript would be illegal.  The idea was that this could make
enums more useful in the strong model.  (In the strong model, enums are
separate types as opposed to disguised integers.)

Somehow I overlooked the fact that this is at odds with the definition of the
subscript operator.  If "hue[RED]" is an int, and is the same as "*(hue+RED)",
then "hue" must have a type T such that T+enum yields "int *".  There is no
such type.  (Logically, it's the type you get if you subtract an enum from a
pointer, but this is an illegal operation in the strong model.)

I see a few ways to salvage this:

[0] Accept the weak model of enums.  In this case we aren't adding anything.
(If enums are just ints, they can already be used as subscripts; the only
advantage is the notational convenience in declaring the array.)  We lose the
typechecking (detection of non-enum subscripts).

[1] Legalize the operation "pointer - enum".  You can add an integer to this
type, yielding the same type.  You cannot dereference it.  You can add an enum
(of the correct type), yielding a normal (dereferencable) pointer.  This seems
quite kludgy, but may be workable.  (How do you declare an object of this new
type?)

[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.

>[I] would like to see it implemented as an extension.  If it catches on, it
>may be a candidate for the __STDC__==2 release.

Suddenly, even __STDC__==3 seems optomistic.  Unless I've missed something?

Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint