Conformant Arrays in C

[Richard A. O'Keefe]

In article <996 at PT.CS.CMU.EDU>, edw at IUS1.CS.CMU.EDU (Eddie Wyatt) writes:
> In article <708 at cresswell.quintus.UUCP>, ok at quintus.UUCP (Richard A. O'Keefe) writes:
> >     I could write a hymn of praise to tagged unions, discrimination
> >     case statements, and polymorphic types, and an execration text
> >     for untagged unions, but let's keep it down.
> > 
[Recall that this started with me saying that C/C++ compatibility didn't
 strike me as important because I thought C++ would be a better language
 without some of C's features, and having been challenged to name five
 such features, I named six.  C's unions are what they are, and a good C
 programmer will learn to live with them.  I do not advocate changing C.
] Wyatt writes:
> There are tradeoffs in requiring or not requiring tag fields.
> It's the space vs readablity problem again.

I can't really agree.  In Wyatt's own example, he makes it plain that
the information as to what his unions are is held in a field, it's
just that the field is somewhere else.  If you are storing information
about a union somewhere, what's so terrible about storing it as part
of the union?

There is something of a cultural conflict here.  My basic preference is
for languages like Simula and ML, where there is no such thing as an
untagged union, and you don't have to debug using-the-wrong-union bugs
because they just can't happen.  This goes with a view of what a union
*is*, which says that 'union' ("sum" types) is the categorial dual of
'struct' ("product" types), that the "fields" of a union are injection
functions, and it goes with a pattern-matching programming style (the
Simula INSPECT statement, for example).  On the other hand, C has
nothing but untagged union, which goes with a quite different view of
what a union is, namely that it is a storage overlay.  Pascal tried to
compromise, which meant that it offered neither the security of sum
types nor the storage efficiency of untagged unions.

I think everyone will admit that sum types are theoretically clean,
and that union types are riskier.  Further, sum types are better news
for optimising compilers.  I think we can discount the "space saving"
argument:  if space saving were of paramount concern in C, it would
have dynamically allocated arrays, not fixed-size arrays.  As for
transmitting things over networks, presumably there is some reason
why SUN's XDR coding doesn't pack things down to byte, but works in
multiples of 32 bits...

C's unions are what they are, and there are legitimate uses of them.
But are they a desirable feature in a successor to C?

Perhaps we can steer this discussion back to something of more immediate
use to C programmers:

    the six points I listed in the message Wyatt quoted:
  o do other C programmers experience them as nuisances?
  o how do people work around them?