joemu@tekecs.UUCP (10/21/84)
I would like to pose a question to the user community.
What position should the ANSI committee take regarding enumerated types?
a. leave them out of the language
b. "tighten up" enums so they behave less like regular ints
c. leave them wishy-washy like they're implemented in many compilers
This is not a joke. The question to even have them in the language is
valid. The only real use for enums that we could see was to provide
symbolic names for constants so that symbolic debuggers could access them.
Other than that, it appears that enums could be replaced with appropriate
#defines.
The "tighten up" position is to make them behave much the same as enums
in pascal. There would not be any bounds checking, it would be too "unClike".
My personal opinion is "if it works, don't fix it". But the question is:
Does the current implementation work for the majority of the users or should
we attempt do do something about it? You may reply to me directly or
if you feel your reply is of general interrest, post it.
UUCP: ...!{ucbvax or decvax}!tektronix!tekecs!joemu
ARPA: tekecs!joemu.tektronix @ udel-relayarnold@ucsfcgl.UUCP (Ken Arnold%UCB) (10/24/84)
> I would like to pose a question to the user community. > What position should the ANSI committee take regarding enumerated types? > a. leave them out of the language > b. "tighten up" enums so they behave less like regular ints > c. leave them wishy-washy like they're implemented in many compilers > > This is not a joke. The question to even have them in the language is > valid. The only real use for enums that we could see was to provide > symbolic names for constants so that symbolic debuggers could access them. > Other than that, it appears that enums could be replaced with appropriate > #defines. I always thought that the most useful potential use for enum's was to replace "appropriate" #define's. Not only is it a regular pain to type 30 or 50 equivalents of # define A 1 # define C 2 . . . . but adding new ones in order is a real pain. For example, adding a definition of "B" to the above list in alphabetical order requires renumbering "C" and everything after must be renumbered if the numerical ordering is to match to actual order (which makes sorting easier). With enums, just an insertion into the list will do the same job. The idea of having constant available to debuggers by name is nice, too, but not as functional. So I would add d. make enum constants be considered exactly like integer constants. Although you can get away with this kind of usage, lint complains like hell about using enum constants for subscripts, etc. I would agree that the current implementation is half-assed and doesn't really solve any problem. I would argue that either enums should equal integers or they should be deleted. Ken Arnold
jss@sftri.UUCP (J.S.Schwarz) (10/30/84)
> So I would add > d. make enum constants be considered exactly like integer > constants. > This is exactly what the Aug 21, Draft of the ANSI standard says. Section 2.3.4: "An identifier declared as an enumberation constant has type int." Section 5.2.3: "The properties of an object of enum type in an expression are identical to those of an int." Jerry Schwarz Bell Labs Summit, N.J ihnp4!btlunix!jss