Uh... destructors?

[Robert Jacques]

On Tue, 22 Feb 2011 01:08:38 -0500, %u <wfunction at 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.