Introduction and Motivation：

• Type Compatibility Issues with Anonymous Types：在讨论改进标记兼容性时，发现使同一翻译单元内的所有无名类型兼容会导致 C 中的类型安全问题，如之前的代码片段中，两种看似兼容的类型在翻译单元内会违反安全性，此规定已从[N3037]中删除。对于解决该问题的其他推测，如使所有匿名结构相同但在typedef声明内嵌套时除外，尚未正式提出，且这种方式直觉上不合理。
• Lack of Structural Typing：其他代码中存在逻辑上相同的结构重复定义，如在 Andre Weissflog 的 sokol 库中，不同的范围定义类型因当前兼容性规则不兼容，作者表示创建不同类型只是为了编译时优化，希望 C 有可选的结构类型结构，这也是一些开发者在协调大型项目时的常见问题，像 OCaml 等语言的结构类型系统只考虑成员来确定类型兼容性，而 C 目前并非如此。
• Macro-generic Data Structure Issues：Martin Uecker 的[N3037]使在 C23 中具有相同内部内容的同名类型通用数据结构和宏兼容，但对于包含空格或其他特殊情况的类型会有问题， workaround 是使用typedef，但仍存在无法使无名类型在单个翻译单元内与其他类似类型兼容的问题。
• A Solution：提出新关键字_Record和_Record( record-attributes … )，创建新的记录修饰符来改变类型的兼容性考虑方式，以解决上述问题，允许在不影响现有代码的情况下，明确控制不同库之间的兼容性和共享。

Design：

• Syntax：_Record是新关键字，用于类型定义的声明符中，在struct或union的标记类型与标识符之间，且在属性规范序列之前，每个类型定义必须一致，有_Record或没有，向前声明不能包含_Record。
• _Record for Macro-Generic Datastructures：通过将结构定义为带有_Record的空结构，可避免非标识符类型名的问题，在文件和函数范围内均有效且无兼容性问题。
• Shared Space vs. Fully Closed：_Record类型的语义是宽松且共享的，即比较、参数传递或赋值的两侧只需有一个结构或联合带有_Record即可，但这会带来基于“病毒”兼容性的类型别名分析问题，如在不同翻译单元中使用_Record可能导致别名问题，对于如何解决此问题，提出了三种行动方案，建议选择等待内存模型 TS 产生的解决方案。
• Generic Selection：代码库中通用选择的使用将受到此更改的影响，因为使用类型兼容性作为改进机制，但目前通用选择基于更好、更严格的类型匹配语义存在问题，未来将有后续论文解决通用选择问题。
• Vendor Implementation Space：用户希望有更多自定义逻辑来处理兼容性问题，如使具有相同字段顺序和类型但不同顶级和字段名的结构兼容，通过_Record( … )语法提供扩展空间，实现可以注入自己的供应商特定语义，未知的_Record( … )声明会导致编译失败。
• _Record(types) for even MORE Compatibility Adjustment：作为_Record的补充，使用_Record(types)语法使具有相同类型布局但不同名称的类型兼容，目前仅提供_Record(types)或裸_Record/_Record()，无需考虑记录修饰符中的多个属性。
• (NOT PROPOSED) Future Direction: _Record(const) for (nested) qualifier Compatibility Adjustment：提出新的记录修饰符_Record(const)，可能解决因某些限定符导致类型不兼容的问题，鼓励实现实施_Record(vendor::const)并报告问题。