N2105 - Compatibility of enums, structures, and unions in the same translation unit

Author: Martin Uecker 


0. 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.