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.
