The great inapplicable attribute debate

[Stewart Gordon]

It's cropped up on a number of occasions.  And again in the comments on
http://d.puremagic.com/issues/show_bug.cgi?id=2830
http://d.puremagic.com/issues/show_bug.cgi?id=1441
which are essentially the same as each other.  The basic matter of 
debate is: If an attribute is applied to something to which it is not 
applicable, should it be an error, silently ignored or what?

There are a number of cases to consider:

(a) Attributes that state what is already implied by the context.  For 
example, module-level functions are effectively both static and final.

(b) Attributes that don't make sense in the context.  For example, 
trying to apply scope to a function.

(c) Attributes that make sense in the context but are nonetheless not 
actually applied.  The issue brought up in the above bug reports is an 
example - actual compiler behaviour even _contradicts_ the fact that a 
protection attribute has been specified.

One recent comment referred to inapplicable attributes generally as 
"'pointless' attributes".  This may be a valid label for (a), but 
certainly not (b) or (c).


At the moment, the problem seems to be that the compiler is silently 
ignoring many cases of (a), (b) and (c) alike.  Some people argue that 
the spec doesn't forbid such use of inapplicable attributes explicitly, 
and so the compiler's treatment of these cannot be called a bug.

I argue that this isn't right.  Nothing I've managed to find in the spec 
states or implies that such obviously wrong code is allowed.  So, by 
applying common sense, one would conclude that it isn't allowed.


Perhaps what complicates matters further is that D has three ways of 
specifying attributes:

(i) as part of the declaration itself
(ii) in a block delimited by { }
(iii) with a colon to apply to everything that follows until the end of 
the scope

It would be annoying to have to avoid (iii) just because you want to 
declare something of a kind to which the attribute is inapplicable later 
in the file.  This may also apply to some degree to (ii), but any use of 
an inapplicable attribute (at least of case (b) or (c)) by (i) is bound 
to be a mistake.

There are also attributes, such as align and (I think) extern, for which 
applying to a compound type is equivalent to applying to all of its 
members.  This should be allowed wherever it makes sense to the context, 
since it would be annoying (for example) to be prevented from declaring 
an alignment on a struct as a whole just because it contains functions.


Basically, what we need to do is:

- Eradicate all cases of (c), fixing it so that the attribute actually 
works in such cases.
- Make sure all cases of (b) generate a compile error when used by (i).
- Define some clear rules on when an attribute may be used by (ii) or 
(iii) if it is inapplicable to some of the entities to which the 
programmer has tried to apply it.


Comments?

Stewart.