This is an unofficial snapshot of the ISO/IEC JTC1 SC22 WG21 Core Issues List revision 110b. See http://www.open-std.org/jtc1/sc22/wg21/ for the official list.
The definition of layout-compatible POD-struct types in 11.4 [class.mem] paragraph 14 requires that the two types
have the same number of members, and corresponding members (in order) have layout-compatible types (3.9).There does not appear to be any reason for including member functions and static data members in this requirement. It would be more logical to require only that the non-static data members of the two types must match.
The characteristics of layout-compatible types are not well described in the current wording, either. Apart from their use in 11.4 [class.mem] paragraph 16 to define the term "common initial sequence," there appears to be nothing said about which operations are possible between objects of layout-compatible types. For example, 6.8 [basic.types] paragraphs 2-3 give certain guarantees regarding use of memcpy on objects of the same type; it might be reasonable to assume that the same kinds of guarantees might apply to objects of layout-compatible types, but that is not said. Similarly, 7.2.1 [basic.lval] paragraph 15 describes permissible "type punning" but does not mention layout-compatible types.
Proposed resolution (10/00):
In 11.4 [class.mem] paragraphs 14 and 15, change all occurrences of "members" to "nonstatic data members."