🚀 go-pugleaf

In a recent article sher@rochester.UUCP (David Sher) wrote:
>I just tripped over another "feature" of c++.
>This feature is that enums are not types.  
>They look like types but really are synonomous with sets of 
>constant definitions and typedefs of ints.  This strikes me as wrong...

I am reminded of a long-standing pet peeve of mine: I can get
type-checking on structures and unions. I can get type-checking
on primitive types (int, float, ...). I CANNOT get type-checking
on datatypes declared via 'typedef' EXCEPT in terms of their underlying
types. (I assume this all is still true in the new language standard.)

What I would like is for typedef names to be considered by the compiler as 
DIFFERENT from the underlying types. The compiler should then allow an implicit
(or explicit) cast back and forth between the derived and underlying types - 
this will avoid breaking existing code. The improvement over the current state 
of things will happen when I ask the compiler "please tell me about possibly 
nasty implicit casts!"
 

Note 1: people who are in the habit of doing things like:

        typedef unsigned char    ubyte;

   and who want to use this new feature will have to switch to:

        #define ubyte  unsigned char

   unless they really want "ubytes" to be non-computable.

Note 2: At some point (of course) you have to give a value to a derived-
   type variable. If you compile habitually with the new message turned
   on, then in such a situation you'll have to use an explicit cast.

Note 3: The same principle could be extended to structures that are equivalent 
   though not identical and to enum's.

Is it reasonable? Is it hard to implement? Comments? (Followups to
net.lang.c, pls).
-- 
garry wiegand   (garry%cadif-oak@cu-arpa.cs.cornell.edu)