🚀 go-pugleaf

Reader who have lost track of what we're discussing in this notes flame are
reminded that my original suggestion was simply that the first sentence starting
on the 15th line of page 173 of ARM be removed.  My reasoning being that
the requirement that the addresses of members be ordered, without requiring
those members be contiguous, is not very useful to C++ programmers.  If the
language did require members be contiguous [kind of difficult, in the presence
of nasty bits like vtable or vbase ptrs] then having ordered addresses would
be useful.  But the language doesn't promise that.  If someone has examples 
where knowing the address order of members in a labeled section is useful 
without requiring the members be contiguous, I'd be interested in knowing it.
In the strict sense, "higher address" only means something within the context
of the contiguous elements of an array, anyway.  [I don't intend to imply
that ordering in arrays be removed :-]  In an extern "C" construct, presumably
you know you don't have nasty bits, and to maintain compatibility with your
C compiler your C++ compiler needs to place members "next" to each other
and at increasing addresses.

Some respondents have insisted to do practical programming, they need to be
able to assume a compiler places members next to each other.  Fine, I don't
disagree with these needs, its just that the language already does not
promise members be "next" to each other.  Insisting members be next to each
other would disqualify many interesting object models, so there are also some
good reasons not to add this constraint to the language.  My position is 
simply that given the language does not guarantee members be "next" to each
other, it doesn't make much sense to require them be ordered with respect to
address.  So I suggest that the sentence on the 15th line of page 73 be 
removed, and that packing order be left to be determined by the needs and
demands of customers.  Personally, at least in the near term, I believe
customers are going to insist on maintaining close compatibility with "C"
compilers, because a lot of "C++" programmers are going to continue to use
"C" coding practices.  I just don't believe this should be enshrined in the
language definition, where it might prove a nuisance at some future date.
The counterposition is, heck, just leave the 15th line of page 73 in for now,
nobody can really make any good use out of it anyway.  And then, if and 
only if, it proves a nuisance in the future, we'll just have to revise the 
language spec.  I'm just sorry this discussion has generated so much more
heat than light.

[PS: I am not Microsoft]