Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site watmath.UUCP
Path: utzoo!watmath!kpmartin
From: kpmartin@watmath.UUCP (Kevin Martin)
Newsgroups: net.lang.c
Subject: How should 'enum's work?
Message-ID: <9576@watmath.UUCP>
Date: Wed, 24-Oct-84 20:26:34 EDT
Article-I.D.: watmath.9576
Posted: Wed Oct 24 20:26:34 1984
Date-Received: Thu, 25-Oct-84 03:28:09 EDT
Organization: U of Waterloo, Ontario
Lines: 67

Subject: Enums: What should they do?
Newsgroups: net.lang.c

Here are my ideas on the way ENUM's should work. Some compilers are more
strict than this description, others are more lax.

An operation on a enum acts like the same operation on an int of the
same value. If the operation happens to yield an integer which does not
have a corresponding identifier in the enum list, tough. This can happen
either because the user has run off the end of a list (i.e. lack of
bounds checking), or the user has used explicit values to generate gaps
in the valid enum values.

The operations
   ++enum
   enum++
   --enum
   enum--
   enum += int
   enum -= int
   enum = enum_of_same_type
   &enum
are allowed on enum lvalues.

The expressions
   enum + int
   enum - int
yield an enum of the same type.
 
When an enum is wanted as an array subscript, or dimension, it is
implicitly converted to int. Similarly for adding a pointer to an enum.

Integral expressions are automatically promoted to enum if needed.

For assignment to an enum and compares between enums, both operands
must be of the same enum type (or a promoted int).  Similarly, when
switching on an enum, the case constants must be either integral, or
enum of the correct type.

In other cases where the programmer wants to convert int<->enum or
between enum types, explicit casts may be used.


Basically, this model does enum's similar to Pascal's enumerated types:
You can take the predecessor/successor (or the n'th pred/succ), you
can assign them, compare them, and subscript them. The main difference is
that the inverse of Pascal's ORD function need not be explicitly coded.

I have less sympathy for programmers who assign sparse values to enums,
then expect that ++ will continue to act like SUCC in Pascal.
Also, consider having valid values for a number, say from 1 to 100. The
values 1, 42, and 86, and 99 are important, and you want to name these
4 values with a sparse enum type. You shouldn't have to name all 96 other
values just so that ++ works the way you want it to.  (although you should
have to name 100 to ensure that the variable has enough range)

---->Start of flame-thrower target range<----
If you want to get fancy, you could enforce that *only* the enum type
used in the dimension of an array declaration may be used to subscript
that particular array...

The conversion of an enum to char * through a direct cast should yield
a string giving the enum identifier. (or some fault if you try to convert
a value that's doesn't have a matching enum identifier)
--:-) End of flahe-thrower target range (-:--

                    Kevin Martin, UofW Software Development Group