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

[Mark Mitchell]

Geoffrey Keating wrote:

>> A typedef declaration which adds semantic attributes to a non-class
>> type is valid, but again creates an entirely new type. 

 >> It is invalid to
>> do anything that would require either type_info or a mangled name for
>> "Q", including using it as an argument to typeid, thowing an exception
>> of a type involving "Q", or declaring a template to take a parameter
>> of a type involving "Q".  (We could relax some of these restrictions
>> in future, if we add mangling support for attributes.)
> 
> Declaring a function which takes a 'Q' also requires the mangled name of 'Q'.

Good point!

>> where T is some invented type name different from all others in the program.
>>
>> For example given:
>>
>>    __attribute__((packed)) S v;
>>
>> the type of "&v" is "__attribute__((packed)) S *", and cannot be
>> passed to a function expecting an "S*", but can of course be passed to
>> a function expecting an "__attribute__((packed)) S *", or a typedef
>> for such a type.
> 
> ... except that there can't be any such functions.  You could assign
> it to another variable of the same type, or a field of a class with
> that type.

Right.  And, since there seems to be consensus that you shouldn't be 
able to apply semantic attributes to class types, "packed" is a bad 
example there too.  (If you applied "packed" at the point of declaration 
of "S", then "S" has a different layout than it otherwise would, but we 
don't need to do anything regarding mangling, etc.)

Thanks,

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713