I think they might very well have considered the case, but simply not
wanted to add "except for redundant public specifiers" to the
complicated rules.
From the discussions I've seen between committee members on
comp.std.c++, I _seriously_ doubt that's the case. I've always gotten
the distinct impression that they want the standard to be as complete
and accurate as possible, and are willing to put almost inordinate
effort into ensuring that even strange corner cases be specified
correctly.
My guess is that with a bit of care, the rules could be reworded to fit
this requirement in fairly naturally -- e.g. to say that in a POD
struct, there may be no access specifier between any two variable
declarations.
Then we have better fix them, rather than changing the language to
accomodate buggy programs.
They're not buggy. They produce code that's absolutely correct -- and
the ones I've seen put the redundant access specifiers there for a
reason: they're (generally) placeholders with comments telling you what
kinds of things to put in each section. They put a framework in place,
and explicitly put in "blank" spots for you to fill in the details.
Sometimes, however, you don't need to fill in every detail, which can
leave a redundant access specifier.
The C++ language inherits PODs from the C language. As soon as we add
access specifiers to a structure, we have already left C land so they
are not PODs anymore.
Not really true -- C+++ "inherits" a form of struct from C, and that
form is a POD. As is perfectly rasonable in inheritance, however, C++
also extends the definition of POD somewhat, adding a considerable
number of things that aren't directly available in C. Nonetheless, the
intent is clearly that these remain layout-compatible with some similar
struct in C.
The thing is that some structures are guaranteed to be compatible with
C. We call them PODs. Some other structures just *might* be compatible
as well, we just don't have any guarantees.
The problem is that right now, a POD struct isn't guaranteed to be
compatible with C either.
Seeing that the C++0x draft is already over 1000 pages long, I don't
think we need any more corner cased added to it.
Maybe not. Then again, there are times that fixing something actually
makes the result shorter and simpler...