Question

I was making a simple class for a small project and decided to just add a destructor for a quick impl instead of using IDisposable, and I came across a compiler error whenever there is a destructor with an access modifier on it.

public class MyClass
{
    public ~MyClass()
    {
        // clean resources
    }
}

I tried public, private, protected and internal. It worked fine with no access modifiers. Since this article shows that the ~destructor is essentially syntatic sugar for a protected Finalize function, it strikes me as odd that you cant use at least protected on the destructor. The article does say “Destructors cannot be called. They are invoked automatically.” Is this how that behavior is enforced?

I ended up just implementing IDisposable anyway, but I am curious… is there some other reason why you cannot put access modifiers on a destructor?

Answer 1

The accessibility domain of a member declared in source code consists of the set of all sections of program text in which that member may be accessed.

An accessibility modifier modifies the contents of the accessibility domain.

An interesting fact about accessibility modifiers is that an accessibility modifier always makes the accessibility domain larger or keeps it the same size. An accessibility modifier never makes the accessibility domain smaller.

We desire that the accessibility domain of a destructor be always empty. That is, it should never be legal to access a destructor in any region of program text.

The reason for this is because we wish to provide to you the enforced invariant that a destructor for a particular instance is run exactly once in the lifetime of the object, at the end of said lifetime. (“Resurrection” of dead objects during finalization brings up interesting issues which I will discuss at a later date.) By disallowing access to the destructor we ensure that user code never calls a destructor early.

Therefore it would be foolish of us to allow the user to increase the size of the accessibility domain; we do not want to hand the user a tool to defeat this carefully-considered aspect of the design of the language.

Did you want to defeat this safety feature? Why? Can you describe a scenario in which it is important that you be able to call a destructor from some region of program text?

the destructor is essentially syntatic sugar for a protected Finalize function

Correct. The specification notes this in section 10.13. And note that the accessibility domain of the allegedly protected “Finalize” method is also empty; it may be neither overridden nor called.

We could have chosen some completely different mechanism to implement destructors, but that’s the one we chose. The fact that we happened to choose some particular implementation strategy for the destructor feature has no particular bearing on the fact that the accessibility domain of a destructor should be enforced to remain empty for safety reasons.