Braced initializers (again)

[Blair P. Houghton]

In article <12987 at smoke.BRL.MIL> gwyn at smoke.BRL.MIL (Doug Gwyn) writes:
>In article <265C5E18.4200 at paris.ics.uci.edu> rfg at ics.uci.edu (Ronald Guilmette) writes:
>>I believe that he [Blair] has indeed located a contradiction that requires
>>correction (and not just clarification).
>
>Now, hey, I'm the one who pointed that out.

Well, hey, you didn't actually point it out, you simply
said it was there, and even then you had it wrapped in a
much larger indication of ambiguity; and, Ron is saying he
agrees with me that an interpretation won't be sufficient.

I don't know the exact definition of "interpretation" as
CBEMA and X3J11 would define it, but if it's what I think
it is (i.e., "putting into other words an existing statement"),
it can't be done given the current statements in the standard.

The "interpretation" will instead have to be a "redefinition".

I'll agree with your "correction is out of the question"
insofar as it's way too soon after the finalization of
the standard to rewrite the thing.  Some time should be
taken so that more of these things can be found, or it will
become ridiculously expensive to the entire industry to
even have a standard.  Otherwise, we might as well have
spent the time and money on cross-compilers and MyC-to-YourC
translators.

Is there any way to elect and publish amendments to an ANSI
document without having to reapparove and reprint the
entire thing?

>Indeed, it's my main
>reason for thinking the alternative interpretation that I've been
>proposing needs to be seriously considered as the one intended.

I think that if you keep the implications of the examples
(pp. 73ff.) you can get the sense you want.  The basic rules
seem to be:  "If the left brace aligns with the first named
member of an aggregate, then the brace-enclosed
initializer-list initializes the entirity of that
aggregate; otherwise it initializes the scalar[*].  If the
first member of an aggregate aligns with no left brace in
the initializer-list, then the aggregate is initialized by
taking the initializers in the order in which they appear
in the initializer-list; initializers 'left over' when the
aggregate is fully initialized will be used for the next
object, if the aggregate was part of a larger aggregate.
An aggregate is an aggregate is an aggregate, no matter
whether it contains or is contained by other aggregates."

The alternative, as Ronald says, and I prefer this one,
would be that "initializers for aggregate objects, whether
they are members of other aggregate objects or not, shall
have braces".  But, this contravenes just about every example,
and may break existing code, which is why I'd support the
other definition.

[*] The rules already exist for what happens if you try to
initialize a scalar with an initializer-list that has
too many things in it; and it seems to say that the commas
could be taken as comma-operators in an assignment-expression...
here you need an interpretation... would the comma-operator
take precedence over the comma-separator, or vice versa?

				--Blair
				  "Uh-ohhhhhh..."