Proposed semantics for attributes in C++ (and in C?)

[Chris Lattner]

On Oct 15, 2006, at 3:12 PM, Mark Mitchell wrote:

> A typedef declaration which adds semantic attributes to a POD class  
> type with no function members is valid, but creates an entirely new  
> type, different from all other types except others formed by adding  
> the same combination of semantic attributes to the same original  
> class type.  In the example above, if the typedef adds a semantic  
> attribute, you may not pass an "S" to a function expecting a "T" or  
> vice versa.  Neither may you pass an "S*" to a function expecting a  
> "T*", without an explicit reinterpret_cast.  The name of "T", for  
> linkage purposes, is "T", and there is no implicit "T::S" type;  
> instead, however, there is a "T::T" type.  (Various consequences  
> follow; for example, typeid(T) gives you a type_info object that  
> indicates that the name of the type is "T".)

Note that this is an ABI change for any code that uses these.  I  
agree that it seems cleaner to just disallow this practice entirely,  
particularly if it is a recent invention.  In any case, having the  
compiler reject code that does not or will not work is a much better  
position to be in than silently miscompiling code.

-Chris