On Tue, 22 Feb 2011 01:08:38 -0500, %u <wfunct...@hotmail.com> wrote:
dmd is pretty lax about attributes which don't apply. It generally just
ignores them. Personally,
I think that it should error on invalid attributes, but for some reason,
that's not how it works.
Of course, there could be other bugs in play here, but there's every
possibility that the end
result is completely valid.
Well, the trouble is, pretty much all of these are invalid attributes:
- const and pure make no sense, since destructors (should) change an
object's state
const is perfectly valid; From one perspective, you're rarely changing the
actual object state, just free-ing allocated resources. From another, you
might be logging something and don't want to accidentally change a value.
pure, especially weak purity, is expected from most destructors (and
functions for that matter). And given that destructors should be able to
be run on a GC thread, disabling access to TLS variables is perfectly
valid.
Now, put the two together and you do end up with your hands mostly tied,
but asserts are still valid as is (IIRC) freeing memory.
- override and final make no sense, since destructors obviously aren't
ever overridden... they're
always called after the subclass's destructor is called
Regarding override, all class destructors are implicitly override, in
which case the extra modifiers make no semantic difference. But module
destructors are not virtual, so override doesn't make sense.
Regarding final, it also makes sense for classes (i.e. preventing
inheritance), but again module destructors are not virtual, so final
doesn't make sense in this context.
- static obviously makes no sense
As stated by others, this is a module destructor, which are declared using
the static keyword.
- synchronized is meaningless since there's only one thread ever running
the destructor anyway
Well, synchronized(monitor) would make perfect sense (since module
destructors are run whenever a thread shuts down), and as there should be
a way to manually set/get the implicit synchronized monitor, this is valid.
- private makes no sense since (unless we're trying to imitate C++ here)
destructors are only
called from the runtime, and nowhere else.
Well, this comes from the fact that all functions have a protection
modifier (private,package,protected,public,etc). So it's perfectly valid
to stick whichever one you want on it, since none of them apply and one
must be present.
