guido@boring.UUCP (01/31/85)
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."
kpmartin@watmath.UUCP (Kevin Martin) (02/08/85)
In article <6301@boring.UUCP> guido@boring.UUCP (Guido van Rossum) writes: >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? At our site, one of our observations is that people can't count past three, especially when the things being counted are all identical (e.g. the leading commas in your scheme). At least for a structure, there is stuff between the commas to keep you from going cross-eyed reading it. >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. There is no reason why a name-the-element selective initialization (such as my suggestion) can't also apply to structures. Actually, with structures, there is a much better chance that, in adding an extra element, you end up with a type mismatch, such as initializing a pointer to 42. >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. New elements should be added in a position which gives the greatest self-documenting properties. Kevin Martin, UofW Software Development Group