Victor Bazarov wrote:
Destructors are most often called implicitly. If you define one
that takes arguments, what arguments would you want the system to
pass?
None, just like with constructors.
I think your argument applies just as well to constructors, which,
after all, are called implicitly with no parameters when an array
is declared. But we don't consider it a problem that one can also
write constructors that take parameters.
However, I suggest that putting destructors with parameters into
the language is still a bad idea. Here is why:
Reason 1
Conceptually, there are usually lots of ways to make something,
but only one way to make it go away.
On the off chance that you can think of several ways to destroy an
object, you can still implement this in C++: store some indication
in the object about how it should be destroyed. The destructor
looks at this and acts accordingly.
Thus, multiple destruction methods can already be done, and it
seems rare enough that it is hardly worth adding new complexity
to the language.
Reason 2
{
Foo x;
x.~Foo(param);
}
x gets destroyed twice: once when I do it explicitly, and once
implicitly when it goes out of scope. This is bad.
Of course, one can call a destructor explicitly even in the current
version of C++, but it is rare, and so when we do it, we often
think carefully about what is happening.
So the real problem with destructors with parameters is that they
make calling a destructor explicitly seem "normal", despite the
fact that it is dangerous.
