🚀 go-pugleaf

>David Baraff proposes that enums have stricter type checking.  He
>gives the example
>
>-------------------------
>enum color { RED, GREEN, BLUE };
>enum fruit { APPLE, PEAR };
>
>color foo()
>{
>	return PEAR;		// I say this should cause a problem
>}
>-------------------------
>where he would like the compiler to complain.

This confuses me somewhat, as well.  Having the greatest respect for
Dr. Stroustrup's judgement, I'm sure there is a good reason for it,
but I can't think of what it might be just sitting here.  I just
wanted to point out a few more potential advantages of strong type
checking for enums.

Note in the example above that ORANGE would be a natural member that
might be added to both the "color" and "fruit" types.  This is
presently illegal, but if we had strong typing for enums it could be
legal.  The type information would eliminate ambiguity.  (This could
be implemented in a cfront-like translater by qualifying each enum
constant with the enum name, just as is done with class members.)

To further enhance the similarities between enums and classes, perhaps
it would make sense to allow enum inheritance.  If we had

enum color { RED, YELLOW, BROWN, GREEN, BLUE };

I think it would be useful to be able to write

enum low_freq_color: public color { RED, YELLOW, BROWN };

and

enum high_freq_color: public color { GREEN, BLUE };

A "sub-enum", as a specialization of an enum, must contain a subset of
the base enum's values.  Another thing that would seem to make some
conceptual sense would be to make all enums subclasses of "int"
(considered as an enum).  Thus, the "switch" statement needs to take
an "int" -- if we write a switch that dispatches off a variable of
type "int", any value is legal in a "case", but if we use a variable of
an enum type in the "switch", the "cases" (except for DEFAULT:) must
be drawn from the set of values in the enum.  This would prevent some
errors.  Perhaps we could have another kind of "switch" statement, as
well, that produces a compiler warning if there isn't a case for each
enum value.

Anyway, I realize that 1) there may be many things wrong with the
above ideas, and 2) Dr. Stroustrup no doubt considered this in the
course of design (it's not too different from Pascal subranges), and
has a set of excellent reasons, conceptual and/or pragmatic, for not
taking this kind of route, and 3) even if these are excellent ideas
that he didn't think of, it would probably be impractical to add them
to the language at this late date.  So I don't mean this article as an
attempt to change the language, but more as an exploration of what
might be done in the language design space.  In closing, let me point
out that there are a couple of pieces of programming discipline that
we could use to approach the extra safety strong enum type-checking
could give us:

1) Always explicityly qualify enum member names with the name of the
enum.  If we write

enum color { COLOR_RED, COLOR_GREEN, COLOR_BLUE };
enum fruit { FRUIT_APPLE, FRUIT_PEAR };

then we are less likely to write

color foo()
{
	return FRUIT_PEAR;		// I say this should cause a problem
}

even though the compiler will still accept it.  Also, this convention
allows COLOR_ORANGE and FRUIT_ORANGE to be distinguished.  Finally, if
one is attempting to write a switch statement that should do something
for every member of an enum, always include a DEFAULT: clause at the
end that prints out at least a run-time error:

enum foo { ...many members... };
switch (foo) {
  case FOO1:
  case FOO2:
   ...

  default:
   error("Unhandled switch value (%d) in switch in %s, line %d.\n",
	 foo, __FILE__, __LINE__);
}



--
Dave Detlefs			Any correlation between my employer's opinion
Carnegie-Mellon CS		and my own is statistical rather than causal,
dld@cs.cmu.edu			except in those cases where I have helped to
				form my employer's opinion.  (Null disclaimer.)
--