Type checking for typedef's (new feature)

[Garry Wiegand]

In response to my suggestion of stronger type-checking on typedefs:

In a recent article greg at utcsri.UUCP (Gregory Smith) wrote:
>It *could* be optional.

Yes yes, I thought I said that! (Wouldn't want to make existing code
complain, you know :-).  In time, the warning might become the default.

>The big problem is deciding *when* to issue a warning and when to
>overlook mismatches.  Suppose you have 'typedef int foo;' and 'foo
>i,j,k;'. then obviously i=j is ok, and so is i=j+k. But the '+' sees
>two typedefs in the latter, and has to be smart enough to check them,
>find out what they really are, and bump the result back to 'foo'. And
>if you have 'int q', is j+q of type int or foo? do 'q +=i ' and/or
>'i=j+q' give warnings? If good semantics for this could be worked out,
>it could be a real aid to writing portable programs.

Perhaps it would work out if typedefs were thought of as making a *copy*
of the underlying datatypes. Rules would be:

    1) operations that were available on the original type (such as '+' or
       '=') would still be perfectly legit if ALL the operands were of the
       new type.

    2) Expressions that mixed things up would receive the new warning. Then
       the compiler would convert/cast things to a common type and proceed.
       The most logical choice for "common type" would be the underlying 
       primitive type.
    
    3) The knowledgeable programmer could avoid the warning by explicitly
       casting things so the expression ended up of uniform type. The compiler
       should be smart enough to know when an explicit cast is legitimate
       with respect to its operand, natch.

I have a full-knowledge-of-the-language C preprocessor somewhere in the 
works, and it sounds like this idea has a little value, so I'll see if I
can tickle it in. But I'm still a bit fuzzy on the semantics myself :-)

-- 
garry wiegand   (garry%cadif-oak at cu-arpa.cs.cornell.edu)