P1847 Make declaration order layout mandated

[wg21bot]

P1847R0 Make declaration order layout mandated (Pal Balog)

[wg21bot]

P1847R1 Make declaration order layout mandated (Pal Balog)

[jfbastien]

This is much simpler than P1112 #38. I'd nonetheless like EWGI to explore it an polish the presentation first.

[theres-waldo]

EWG-I in Belfast

Forward to EWG
unanimous consent

Author will add discussion of which implementations have been surveyed to verify they don't make use of the reordering permission.

[wg21bot]

P1847R2 Make declaration order layout mandated (Pal Balog)

[jfbastien]

EWG Prague on Thursday afternoon:

This is a problem that we want to solve.

SF	F	N	A	SA
8	9	3	1	0

This paper should also address is_standard_layout (from P1848).

SF	F	N	A	SA
0	6	9	3	1

Mark this paper as tentatively ready.

SF	F	N	A	SA
3	11	6	0	0

Ask SG10 about the feature test macro. Should it be there?

[wg21bot]

P1847R3 Make declaration order layout mandated (Pal Balog)

[jfbastien]

EWG February 2021 polls:

Poll: Forward P1847R3 "Make declaration order layout mandated" to Core.

SF	F	N	A	SA
12	7	7	1	2

Poll outcome: ✅ consensus.

Chair comment on outcome: this was discussed in-person in Prague and Belfast and had strong consensus, the current objections had been discussed in person, and the request for finer-grained control are addressed in a separate paper (in fact, the paper was separated at WG21’s request).

Salient comments:

• (Against) I’m mildly opposed to nailing down a property of the language that users should probably not depend on in the first place. I realize that the practical impact of doing so is small, but at the same time I’m also not convinced by the benefits.
• (Strongly against) I think the current rules are sensible; they set aside a clearly delineated space for data that must remain layout-compatible over time. Access control is strongly associated with class invariants, whereas invariants can’t be enforced on serialized data. It would not make sense to memcpy data from a file directly into the representation of a class type that maintains invariants. Instead, that data should be deserialized into a standard-layout struct, verified for conformance to invariants, and only then supplied to the class type after verification. The class type can use the standard-layout struct directly as a (private) class member. I’ve certainly seen plenty of code that assumes the rules in P1847 are already in place, thanks to compilers generally following those rules anyway, but I think such code is highly suspect and likely predicated on false assumptions about the validity of deserialized data. I’d prefer that the language did not encourage writing more of this code.
• (Strongly against) I hate that some classes will have a standard, fixed layout, but that is_standard_layout is going to be false for them (and for instance that common starting sequence will become a very hard to understand UB). Even if currently no well known implementation uses the allowed reordering, It seems that such reordering can provide structures with better packing, and an implementation might want to benefit from that eventually. So unless there is another mechanism to mean : Please, compiler, do what you think is best, I don’t really see the point of removing this freedom.
• Standardizing existing practice for an implementation freedom no one found a use for. It is what compilers have been doing for decades; we should be able to rely on it.
• The current layout rules are effectively frozen in this form by ABI compatibility concerns.
• Paves the way for the [[layout(...)]] attribute, which I would really like to see making progress.

[jensmaurer]

CWG 2021-04-12: Approved D1847R4 for plenary vote.

[wg21bot]

P1847R4 Make declaration order layout mandated (Pal Balog)

[wg21bot]

Adopted 2021-06.