If one tries to apply an argument to an entity to which it is not applicable, how is the compiler supposed to deal with the attempt? There has been considerable debate about it both here on Bugzilla and on the newsgroups, and the anomalies have been widely observed. The compiler, under certain conditions, silently ignores such inapplicable attributes. It isn't clear what these conditions are, and there are some conditions under which it should certainly not be happening. There are three kinds of inapplicability to consider: (a) attribute's meaning already implied by the context (b) doesn't make sense in the context (c) makes sense in the context but is nonetheless not actually applied. Issue 1441 (later resurfaced as issue 2830) is a prime example of (c). That any cases of (c) actually exist is bad in itself. We need a clear spec on the whole issue. It should consider not only the three kinds of inapplicability, but also the possible ways of specifying an attribute: (i) directly to the declaration (ii) using { } (iii) using : (iv) inherited by the members of a compound type, in the case of one or two attributes AISI the most lenient policy that is reasonable is: - allow (a) always - allow (b) except when applied by (i) - eradicate all cases of (c) by fixing the affected attributes to work Whatever we do, both the spec and the compiler will need to be amended. Further discussion at URL given.
i, ii, and iii are equivalent as documented. I think that should remain, as it would be very confusing to make them behave differently. Not sure what you mean by iv. Other problems with inappropriate attributes should be handled on a case by case basis. I don't think a general policy will work. Therefore, I'll mark this as wontfix, with the supposition that the various cases should each have their one bugzilla entry.
(In reply to comment #1) > i, ii, and iii are equivalent as documented. I think that should remain, as it > would be very confusing to make them behave differently. Not sure what you mean by this. > Not sure what you mean by iv. I figured that there might be cases (such as align) where applying the attribute to a class, struct, etc. applies it to each of its members.
attribute int a; attribute: int a; attribute { int a; } should all have the same meaning for a.
(In reply to comment #3) > attribute int a; > attribute: int a; > attribute { int a; } > > should all have the same meaning for a. This whole debate is about legality, not meaning. Defining that they always all have the same legality erodes the usefulness of the colon notation especially, since one could try to use it and then be forced to move a declaration to which it doesn't make sense to above the attribute, which can get annoying if you want to place declarations in some intuitive or logical order.