The great inapplicable attribute debate

[Nick Sabalausky]

"Stewart Gordon" <smjg_1998 at yahoo.com> wrote in message 
news:grtr90$1hlh$1 at digitalmars.com...
> 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.
>
>[snip]
>
> 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
>
>[snip]
>
> 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.
>

Absolutely. I think it boils down to this: If something seems to work, it 
should work as expected. Things should either just "work" or "not work". 
_Never_ "it works, but does something completely different".

I think this ticket I filed might also be another case of the same issue:
http://d.puremagic.com/issues/show_bug.cgi?id=2775

I've never even looked to see if the language definition explicitly 
allows/forbids/doesn't-address using "private" on 
templates/structs/classes/unions. But for such a basic and conceptually 
simple language feature, I shouldn't even need to. Don't force me to be a 
language lawyer to use such simple things properly: If I stick "private" in 
front of something, and the compiler *accepts* it, it should "just f*^&*%^* 
work". If for some bizarre reason private templates/structs/classes/unions 
aren't supposed to be allowed (which I *really* hope is not the case), then 
dagnabbit, the compiler needs to speak up. After all, it is the role of the 
compiler to raise an error when the programmer tries to do something that 
isn't allowed, and not to just silently make up some alternative behavior 
(if I wanted to put up with that kind of "principle of maximum silent 
surprises" crap I'd use a scripting language).

Until now I just assumed these were a compiler bugs, but if this "let's let 
the programmer *think* this is working the way they intended" behavior is 
intentional just for the sake of Stewart's (ii) and (iii), well then that's 
terrible and absolutely needs to change.