Path: utzoo!attcan!uunet!cs.utexas.edu!yale!think!snorkelwacker!spdcc!ima!haddock!karl
From: karl@haddock.ima.isc.com (Karl Heuer)
Newsgroups: comp.lang.c
Subject: Re: Enumerated types... what's the point?
Message-ID: <16291@haddock.ima.isc.com>
Date: 26 Mar 90 20:22:30 GMT
References: <1990Mar22.053148.10351@ncsuvx.ncsu.edu> <1990Mar22.164943.10459@utzoo.uucp> <699@sixhub.UUCP>
Reply-To: karl@haddock.ima.isc.com (Karl Heuer)
Organization: Interactive Systems, Cambridge, MA 02138-5302
Lines: 22

In article <699@sixhub.UUCP> davidsen@sixhub.UUCP (bill davidsen) writes:
>I was told that enums as I wanted them were "thinking like Pascal,"
>and "not in the spirit of C."

That's what they said about pointer-vs-integer collision detection, too.  An
idea is *not* automatically bad just because Pascal implemented it first!

ANSI decided to endorse the weak-enum model, but they did give a nod to the
strong-enum model via an acknowledement in the Common Warnings appendix.  I
presume there are a fair number of us who use enums only in the strong model,
so there ought to be a market for a compiler (or a lint option) that enforces
the stricter rules.  Unfortunately, even "gcc -Wall" doesn't seem to do so
yet, but I bet it could be added without too much difficulty.

In my opinion, the rules for strong-enum arithmetic should be analogous to
pointers: enum + int --> enum; enum - enum --> int; enum + enum --> error.
"++" and "--" are analogous to Pascal's "succ" and "pred" functions.  The one
thing you still can't do--and which was, I think, a major reason why the
Committee went for the weak-enum model--is to have an array subscripted by
enum, but this could be faked with a macro.

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