osd7@homxa.UUCP (Orlando Sotomayor-Diaz) (02/15/85)
mod.std.c Digest Fri, 15 Feb 85 Volume 3 : Issue 4
Today's Topics:
Need for first-member union initialization rule
union initialization and paper proposals
----------------------------------------------------------------------
Date: Thu, 14 Feb 85 13:44:07 est
From: cbosgd!plus5!hokey
Subject: Need for first-member union initialization rule
To: cbosgd!std-c
Sam Kendall raises several points (correct me if I'm wrong):
- The first-member rule is consistent with other behavior
- The first-member rule does not prevent a subsequent, more
elaborate solution (I would say "better")
!kendall correctly points out that, given union initialization is permitted,
Something must be done about "default" union initializers. !kendall also
(correctly) points out that if we use the first-member rule, we have a
well-defined mechanism for handling default initialization. Further, if
we use the "cast" method of union initialization (my favorite) then we
need to address the problem of default initialization.
I do not see this issue as one which makes a stronger case for the first-
member rule for two reasons. First, there are several alternatives for
dealing with default initializers under the "cast" mechanism. Second,
the first-member rule is *guaranteed* to be less than sufficient for the
task of initializing unions.
Default initialization under the "cast" method could be handled in one of
the following ways:
- 0 cast to type of first-member
- Erroneous
There may be others. I would prefer that an implicit initialization be
flagged as *erroneous*. This is a restriction which could be relaxed later,
and such a relaxation would be backward-compatible.
> Second, I want to answer the criticism that this rule will prevent
>further extensions along these lines. My answer is very simple: any
>union initialization syntax that attempts to select which member is
>initialized had better look different than ordinary initialization, and
>thus be syntactically distinguishable from it; otherwise things are
>going to be very confusing. (In particular--to make my one
>inflammatory statement of this note--the "cast" syntax for union
>initialization is not even worth arguing about.)
What is wrong with the "cast" syntax? I don't want an argument, but a
discussion would be nice.
The cast syntax syntax is clear. If you prefer keyword initialization,
there is no reason not to have both. Keyword initialization could also
be used for structure initialization.
The first-member rule may not rule out *all* other mechanisms for initializing
unions, but it certainly prevents more options than it allows! There is a
difference between a simple solution and a simplistic one.
!kendall, do you prefer keyword binding? There is *no* reason why it should
not be included, and it does not prohibit the "cast" method. Either solution
is fully functional. They are not mutually exclusive. Permitting both would
be great, as use of either would be a matter of style, preference, or
applicability to the problem at-hand.
Hokey ..ihnp4!plus5!hokey
314-725-9492
------------------------------
Date: Wed, 13 Feb 85 14:29:30 est
From: cbosgd!plus5.UUCP!hokey
Subject: union initialization and paper proposals
To: std-c@cbosgd.uucp
In article <700@homxa.UUCP> henry@utzoo.UUCP (Henry Spencer) writes:
>As far as I know, nobody contends that the first-member rule for union
>initialization is beautiful.
The contention isn't beauty, it is functionality.
>The key point is: there is real live experience with this rule, with a
>real compiler and real customers. In other words, it is known to work in
>practice, not just theory.
I note that you don't state how *well* the proposal works; specifically,
most of the discussion I have seen *against* this proposal is that it does
not provide the degree of power we want. To say it does what it was designed
to do simply ignores the functionality of the first-member rule in a greater
context.
>This is of considerable importance when something is to be enshrined in a
>standard. I'm not aware of comparable real-life use of any of the various
>other proposals. Careful contemplation is *not* the same thing.
Absolutely. Also note that one purpose of "real-life use" is to learn from
mistakes. I have worked on Fortrans which had Print, Write, and Output
statements, each designed to do (more or less) the same thing as its
predecessor, except the "new" one handled a few cases the "old" one didn't.
>Standards committees have good reason for taking field-proven proposals
>much more seriously than untried ones. Avoiding subtle disasters is more
>important, for a standard, than maximizing beauty.
The disaster we would face by the first-member rule is not subtle. It is
acknowledged. Documenting a bug doesn't make it a feature. If a solution
is truly beautiful, it does not have subtle flaws.
Another reason standards committees ratify existing implementations is
because they feel such a move would maximize acceptance of the standard,
or because they wish to avoid a lawsuit or just negative votes. The last
point goes both ways. The first point doesn't seem applicable here because
the population currently using the first-member rule is so small.
>This is not to say that I like first-member union initialization.
>Personally, I think it should have been "done right" (although I'm
>not sure just how to do that) or ignored. If I'd been a committee
>member, in the absence of field-proven "done right" solutions,
>I think I'd have voted for ignoring the whole issue. Oh well.
Should I infer, then, that your article was an academic exercise ;-!
Aren't religious discussions fun?
Hokey ..ihnp4!plus5!hokey
314-725-9492
------------------------------
End of mod.std.c Digest - Fri, 15 Feb 85 08:05:26 EST
******************************
USENET -> posting only through cbosgd!std-c.
ARPA -> replies to cbosgd!std-c@BERKELEY.ARPA (NOT to INFO-C)
In all cases, you may also reply to the author(s) above.
--
Orlando Sotomayor-Diaz /AT&T Bell Laboratories, Red Hill Road
/Middletown, New Jersey, 07748 (HR 1B 316)
Tel: 201-949-9230 /UUCP: {ihnp4, houxm}!homxa!osd7