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

[Mark Mitchell]

Jason Merrill wrote:

> I don't think my patch changed the handling of class typedefs; certainly 
> my intent was only to change how we handle
> 
>   class __attribute ((foo)) C
> 
> Previously we rejected it, now we apply the attributes to the class.

OK, that certainly makes sense.  (That's one of the items in the 
proposal I wrote up: that you can apply attributes at the point of 
declaration of a class.)

> Which PRs are you referring to?

One example is:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28558

However, this is a problem with non-semantic attributes, and not related 
to your patch.  So, I apologize for any aspersions cast.  But, it does 
motivate for writing something down about what we want semantics we 
want.  Here, what I think we want is (as per the proposal) to create a 
new anonymous typedef for "__attribute__((unused)) A", but consider that 
the same type as "A".

I was pretty sure there were other PRs, but I'm not able to find them 
now, so perhaps I was dreaming.  I thought there were also PRs about 
typeid and mangling failing (and/or doing the wrong thing) for types 
with attributes (including scalars with attributes).

> I'd be inclined to prohibit semantic attributes on typedefs in general. 

That's certainly simpler.  I'm happy to be talked out of that idea. :-)

>  Extending the type system to handle attribute types seems excessively 
> complicated.  I think we should define a set of attributes which prevent 
> us from taking the address of a variable with that attribute 
> (packed...anything else?) and check for them at the same places we check 
> for taking the address of a bitfield.

That seems like a good idea to me.  However, one consequence is that a 
packed class cannot have member functions (since you'd never be able to 
get a "this" pointer for them); do you think that's OK?

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