Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83 (MC840302); site boring.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!bellcore!decvax!genrad!panda!talcott!harvard!seismo!mcvax!boring!guido
From: guido@boring.UUCP
Newsgroups: net.lang.c
Subject: Re: Standard for union initialization
Message-ID: <6301@boring.UUCP>
Date: Thu, 31-Jan-85 09:37:45 EST
Article-I.D.: boring.6301
Posted: Thu Jan 31 09:37:45 1985
Date-Received: Sun, 3-Feb-85 07:48:56 EST
References: <137@ISM780B.UUCP> <11143@watmath.UUCP>
Reply-To: guido@boring.UUCP (Guido van Rossum)
Organization: "Stamp Out BASIC" Committee, CWI, Amsterdam
Lines: 26
Summary: 
Apparently-To: rnews@mcvax.LOCAL

In article <11143@watmath.UUCP> kpmartin@watmath.UUCP (Kevin Martin) writes:
>This looks ok for a nice short example like this, but frequently, the
>union's definition and initialization are far apart (and maybe in different
>source files). This makes it easy to add another union element, and
>inadvertantly screw up the initializers royally without as much as a
>peep from the compiler.

Why is this proposal attacked so vehemently?  All arguments I hear
against it (and it is really the same argument all the time) can be
used against structure initialization as well: the meaning of the
initialization depends on the order of the elements in the struct/union
declaration.

So?  Don't change the order of elements when there are initializations
around, or be prepared to hack your way through the program and spot
the initializations.  For unions, the problem of adding another element
is even less of a problem:  since the order of initializations is
unimportant *except for the proposed initialization feature* (this is
true even for the first member rule!), new elements should be added to
the end of the union.

	Guido van Rossum, "Stamp Out BASIC" Committee, CWI, Amsterdam
	guido@mcvax.UUCP

"Life is like a sewer.  What you get out of it, depends on what you put
into it."