"Stewart Gordon" <[email protected]> wrote in message news:[email protected]... > 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.
