N2105 - Compatibility of enums, structures, and unions in the same translation unit Author: Martin Uecker0. Goal Change the rules for compatibility of enums, structures, and unions with the goal of a simpler and more consistent language and to enable simple forms of generic programming. 1. Proposal The specific proposal is simply to remove the condition "declared in separate translation units" in 6.2.7(1): "6.2.7 Compatible type and composite type (1) Moreover, two structure, union, or enumerated types declared in separate translation units are compatible if their tags and members satisfy the following requirements: ..." 2. Simpler and more consistent language Using the same rules for types declared in the same or different translation unit would lead to a simpler and more consistent language. For example, code could be moved between files without causing problems due to changed semantics. It could also simplify compilers which now need to keep track whether definitions are from the same translation unit or not when several translation units are compiled at once (e.g. with link-time optimization). 3. Generic programming The ability to construct compatible types using macros would simplify generic programming using pre-processor macros. Currently such code relies on explicit initialization macros which have to be called before to declare all required types, but this is not feasible in more complicated scenarios. Example: #define VEC3_TYPE(T) struct { T foo[3]; }; #define VEC3_SWAP(T, a, b) \ do { \ VEC3_TYPE(T) tmp; \ tmp = a; \ a = b; \ b = tmp; \ } while(0) 4. Backwards compatibility Because types are now considered compatible which where not some invalid programs would become valid. 5. Impact on optimization It is possible that this proposal could lead to less efficient code in rare cases because more types are compatible. Potential aliasing of pointers could then prevent some optimizations. On the other hand, it seems unlikely that this change would have a big impact as only few types would be affected. In any case, if this proposal is adopted the programmer would have explicit control about whether the types are compatible or not by using identical or different tags. As explicit control is generally considered to be in the spirit of the C programming language, this seems a disable change.