Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site watcgl.UUCP
Path: utzoo!watmath!watnot!watcgl!kdmoen
From: kdmoen@watcgl.UUCP (Doug Moen)
Newsgroups: net.lang.c
Subject: Re: Type checking for typedef's (new feature)
Message-ID: <738@watcgl.UUCP>
Date: Fri, 6-Jun-86 00:18:49 EDT
Article-I.D.: watcgl.738
Posted: Fri Jun  6 00:18:49 1986
Date-Received: Sat, 7-Jun-86 07:27:24 EDT
References: <361@batcomputer.TN.CORNELL.EDU>
Reply-To: kdmoen@watcgl.UUCP (Doug Moen)
Organization: U of Waterloo, Ontario
Lines: 28
Summary: 

garry wiegand:
>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 - 

I disagree.
There are a number of situations when I want to give a name to a type
expression *without* creating a new type as a side effect.

Certainly there ought to be a way to create new types, but this mechanism
should be orthogonal to the mechanism for giving names to type expressions.
Notice that making type naming and type creation into two separate mechanisms
is more flexible than forcing you to always get one with the other.

C++ already has a way to create new types: the class mechanism.

typedef int foo;	/* foo is a synonym for 'int' */

class bar {		/* bar is a new type with representation 'int' */
	int i;
};

To obtain what Garry wants (derived types), we need a way for 'bar'
to inherit all of the operations on 'int'.  There is currently no way
to do this.
-- 
Doug Moen (watmath!watcgl!kdmoen)
University of Waterloo Computer Graphics Lab