typedef laxity

[Mark Brader]

> 	typedef int TEMPERATURE;
> 	typedef int PRESSURE;
> 	TEMPERATURE tx, ty;
> 	PRESSURE px, py;
> 	ty = py;		/* type clash */
> I _know_ how it works.  I am arguing that how it works is a _bad thing_.

People making complaints like this should always include a sentence
like the last one in their *original* posting; it saves on followups.

One advantage of the way it actually works is that you can continue to
use library functions conveniently.  For instance, abs() takes an int
argument and returns an int result.  So you can say:

	py = abs(px); /* never mind the direction, how hard it is pressing? */

Relatively recently, C has acquired the notion that certain conversions
(involving pointer types) can be done only by an explicit cast operator
and not by direct assignment.  Using this concept, the language could
similarly be changed to require that the above be written

	py = (PRESSURE) abs ((int) px);

to allow calling of library functions while also having the stricter typing
that the original poster is calling for.  However, I argue that this would
be a "bad thing", because it is no longer clear in the above form that both
casts shown are guaranteed to give exact conversions.

Of course, once the language allows you to mix PRESSURE and int in this way,
there's not much reason not to allow mixing PRESSURE and TEMPERATURE.  And
while it may seem silly with pressures and temperatures, the use of different
typedefs doesn't necessarily imply that the quantities are incommensurable.
How about
	typedef long CITY_POP, STATE_POP;
?

Finally, if you really want strict checking, you can get it by:

	typedef struct pressure {int value;} PRESSURE;
	typedef struct temperature {int value;} TEMPERATURE;

Then if you want to use them as integers, you have to say

	py.value = abs (px.value);

which is no worse than the cast version; but the direct assignment

	py = ty;

is illegal.  However, I'm certainly not advocating this method!

Mark Brader				"C takes the point of view
SoftQuad Inc., Toronto			 that the programmer is always right"
utzoo!sq!msb, msb at sq.com				-- Michael DeCorte