[basic.types.general] Layout-compatibility seems too restricted

[frederick-vs-ja]

Full name of submitter (unless configured in github; will be published with the issue): Jiang An

Reference (section label): [basic.types.general]

Link to reflector thread (if any):

Issue description:

Currently two types are layout-compatible only in a few cases (ignoring top-level cv-qualifiers at first):

• they are the same type, or
• they are layout-compatible classes, or
• they are layout-compatible enumeration types, i.e. enumeration types with the same underlying type.

There are possibly some other cases in which two types share the same size, alignment, and representation, but not layout-compatible:

• an enumeration type and its underlying type (also mentioned in CWG2590 [dcl.enum] Underlying type of enum should determine its size and alignment requirement #39 ),
• two array types of the same length and layout-compatible but different element types,
  • e.g. Foo[1] and Bar[1], where Foo and Bar are layout-compatible classes,
• two "similar" but different types, but perhaps the pre-C++20 (pre-P0388) similarity should used because similarity is no longer an equivalence relation (losing transitivity) since C++20,
  • e.g. char* and char const*,
• two types T1 and T2, whose U types in qualification decomposition (denoted by U1 and U2 here) are layout-compatible, and they would become similar if U1 and U2 were replaced with the same type,
  • e.g. Foo* and Bar const*,
• signed and unsigned integer type counterparts,
• bool or an encoded character type and its underlying type,
• two other arithmetic types with the same size, alignment, and representation,
  • e.g. int and long in ILP32, or double and long double in MSVC ABI.

This is not strictly a defect, but it's not clear to me whether the current specification is reflecting the intent of design. It might be better to extend layout-compatibility to include some or all of these cases, while keeping being an equivalence relation.

[languagelawyer]

Write a paper 🌚

[jensmaurer]

Our rules for "layout-compatible" have not changed substantially since C++98. Any major change (absent possibly your first point, which feels like a possibly oversight), should be handled by a paper, not a core issue.